[p4] fstat digest of text file (CALL#2327524)

Sergey Klibanov sklibanov at day1studios.com
Fri Mar 27 07:29:41 PDT 2009

Luckily we don't use ktext (at all. It's more trouble than it's
worth..,), so RCS keywords aren't an issue :-)


The trouble with sync -k is that in my case, the files I'm comparing may
not be where the sync would put them - they may be in some far-off
temporary directory. Doing a diff after that would just result in a
missing file.


You guessed correctly by the way - I generate some files (specifically
game-ready animations and skeletons) from source data, and I want to
send an email if someone forgot to check something in, or worse -
checked in an exported game-ready file without checking in the source
data too :P





From: jeff.a.bowles at gmail.com [mailto:jeff.a.bowles at gmail.com] On Behalf
Of Jeff A. Bowles
Sent: Friday, March 27, 2009 9:05 AM
To: Sergey Klibanov
Cc: perforce-user at perforce.com
Subject: Re: [p4] fstat digest of text file (CALL#2327524)


If *I* needed to compare locally generated files against the server's
copy, I would make sure that I could account for RCS keywords and a
number of similar things such as end-of-line.


The checksum idea has merit: md5-checksum the local content, then surf
through the server's stored-checksums and compare. (I have written a
small script for other purposes, that compares an MD5 checksum against a
tree, hoping to find where the file was retrieved from.)




For this specific case, have you considered the "sync" option that
updates database tables but doesn't retrieve content? That, plus a "p4
diff" afterwards, would give you the diff information you seek with less
content traveling back/forth, and would deal with
binary/text/RCS-text/unicode better than many other solutions.


It would be more useful if you described WHY you are comparing...
against the server. I expect that the reasons is, "see if these files I
just generated need to be checked in because they have changed."


   -Jeff Bowles


On Fri, Mar 27, 2009 at 8:24 AM, <tmcd at panix.com> wrote:

On Fri, 27 Mar 2009, Sergey Klibanov <sklibanov at day1studios.com> wrote:
> Benjamin, you asked why... Well, I have an automated process where I
> need to compare locally-generated files against their head revision
> in the depot. The wrinkle is that for a variety of reasons the files
> I need to compare aren't synced on the machine running this
> operation, and may even reside some place other than where the
> client spec thinks they should be. I looked at p4 help diff for a
> bit, but found no way to get it to report diffs for un-synced and
> badly-located files.

Would your problem be solved by "p4 print -q ... > another_local_file"
and calling a local diff program on another_local_file versus your
locally-generated file?

I wonder whether the Perforce maintainers would consider extending
"p4 diff2" to allow a local file as an argument.
says that both regular arguments have to be depot paths.

Tim McDaniel; Reply-To: tmcd at panix.com
perforce-user mailing list  -  perforce-user at perforce.com

Jeff Bowles - jeff.a.bowles at gmail.com

More information about the perforce-user mailing list