[p4] "p4 labelsync": final, I hope

[Robert Cowham]

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.

Robert

> -----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
>        manual.]
> 
> 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 
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>