[p4] "p4 labelsync": final, I hope
robert at vizim.com
Sat Jul 18 03:42:18 PDT 2009
The way I think about labelsync is in terms of sets of files.
There are two sets: WS and L
WS is the set of files in your workspace view (the #have versions).
L is the set of files in the label view.
Let us imagine that the 2 sets intersect so we have:
A - files in WS but not in L
B - files in intersection
C - files in L but not WS
If you do
P4 labelsync -l L
What is put in the label? Which revisions?
What happens if you do:
p4 sync @L
Consider the above in the light of subsets A, B, C
I find this explanation goes down quite well.
> -----Original Message-----
> From: perforce-user-bounces at perforce.com
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of Tim McDaniel
> Sent: 17 July 2009 16:41
> To: perforce-user at perforce.com
> Subject: [p4] "p4 labelsync": final, I hope
> << (I haven't even looked at "p4 labelsync -d".) >>
> I should have. It does exactly the same kind of deletion
> that is done WITHOUT "-d" (as long as "-a" is not specified),
> and which it took me hours to figure out.
> That is, "-d" doesn't do anything special with deletions.
> "-d" simply suppresses adding anything to the label. Just
> like "-a" doesn't do anything special with additions: it just
> suppresses the deletions.
> Gaaaaah. Perforce, your labelsync documentation SUCKS!
> So let me simplify my previous explanation of labelsync's
> basic operation:
> * The user can specify -a, -d, or neither. The user cannot specify
> both -a and -d.
> * If there are no file arguments, assume "//...#have".
> * For each file argument in turn,
> = if "-a" is not specified, deletes the named file pattern from
> the label, regardless of revision. [I called this "step 1".
> This is a phrase from the manual, except that I use "file
> pattern" in case the argument has wildcards.]
> = if "-d" is not specified, add the named file pattern to the
> label, using the revisions specified, or #have if no
> revision is
> specified. [I called this "step 2". Again, adapted from the
> The fact that it processes each file argument in turn is
> significant when file arguments refer to the same files (and
> neither "-a" or "-d"
> is specified). It is then possible for something added by
> one file argument to be deleted by a later one.
> Tim McDaniel, tmcd at panix.com
> perforce-user mailing list - perforce-user at perforce.com
More information about the perforce-user