[p4] diff between two revisions

David Weintraub qazwart at gmail.com
Wed Jan 31 08:22:01 PST 2007


I second you on the output. I don't even know what Perforce is telling
you at that point since those revisions of Makefile don't even exist.
That's the output you expect to see when you do a "p4 sync".

I have quite a few gripes about Perforce.  The command line use is
klutzy with too few command line options, the error messages aren't
very clear, and my biggie, Perforce almost always returns an exit code
of "0" even when the command "fails". This makes writing shell scripts
or Perl scripts extremely difficult since I have no easy way of
knowing when a Perforce command really did what I was expecting.

However, I do like the dual nature of tracking changes via both unique
revision number and with the changelist.

The changelist number is very similar to revision numbers in
Subversion and can be used the same way. It eliminates the need for
labeling each and every build, and it gives you an easy way to look at
a set of changes. However, at the same time, I can treat this like all
other revision control systems and talk about a particular revision of
a particular file. I find most developers like the fact they can refer
to individual revisions of a file.

Where this really shows up is Subversion's inability to remove
unwanted revisions of a file. There is no equivalent to "p4 obsolete".
I've worked at many sites where we version binary files. For example,
we may build a *.so or *.dll, and have this available to other users.
If I cannot remove obsolete revisions of these files, we would quickly
fill up our depot space. Disk space may be cheap, but it isn't free.

In order to remove an obsolete revision in Subversion, I have to touch
dozens of revisions in the archive. The only real option in Subversion
is to reformat the entire source archive (via a dump) and restore it
sans the missing revision. And that has the possibility of renumbering
our revisions (as I found out the hard way).

It can take a bit of time to get use to the way new software works and
to understand it quirks. Once you get use to the dualism of changelist
vs. revision, you'll find a lot of the features in Perforce quite
nice.

On 1/30/07, Jeff Sparks <jeffrsparks at yahoo.com> wrote:
> Just to wrap this up, the problem was of course my confusion between
>  revision number and changelist number.  After years of subversion
>  (where there is no such distinction), the habit is hard to break.
>
>  My mistake was "confirmed" by the following:
>
>      terra% p4 diff Makefile#1499 Makefile#1186
>      Makefile#1499 - file(s) up-to-date.
>      Makefile#1186 - file(s) up-to-date.
>
>  Just try it with any file 'foo' under version control, with any
>  revision numbers:
>
>      % p4 diff foo#9999999 foo#100000000
>      foo#9999999 - file(s) up-to-date.
>      foo#100000000 - file(s) up-to-date.
>
>  Had it not been for this (IMO) misleading output, I likely would have
>  realized my mistake sooner and would not have bothered this list.
>  What is the meaning of this output, anyway?  Isn't it a bug?
>
>  Also, I think the unintended 'wrong' answers from a few folks here
>  regarding '#' verses '@' makes a pretty solid case that the 'revision'
>  and 'changelist number' concepts should be combined (as in
>  subversion).  I don't mean to sound trollish; I just don't see a
>  compelling reason for the distinction.  If they were combined, my
>  hassles would have been avoided altogether.
>
>  --jeff
>
>
>
> ---------------------------------
> Everyone is raving about the all-new Yahoo! Mail beta.
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>


-- 
--
David Weintraub
qazwart at gmail.com


More information about the perforce-user mailing list