[p4] how to make labelsync label deleted files
Michael Van Hoff
perforce-user-forum at forums.perforce.com
Mon Jul 22 07:45:01 PDT 2013
Posted on behalf of forum user 'Michael Van Hoff'.
I did some testing, and I'm not seeing your issue...
I created two files, test1.txt and test2.txt. I added and submitted
them in CL#1234.
I then deleted test2.txt in CL#1235.
I then created my label, 'p4 label DELETE_TEST' and set the view to look
at where these files were in my depot, '//depot/path/...'.
I then sync'd the label, 'p4 labelsync -l DELETE_TEST', but it said
it only added test1.txt.
//depot/path/test1.txt - added
But as you'll see below, it was still aware that test2.txt was to be
I then sync'd the directory to CL#1234, 'p4 sync ... at 1234' to get
both files back and to simulate the state of the client/workspace before the
label with the delete would be applied.
//depot/path/test1.txt#1 - added as C:\workspace\depot\path\test1.txt
//depot/path/test2.txt#1 - added as C:\workspace\depot\path\test2.txt
I then sync'd to the label, 'p4 sync ... at DELETE_TEST' and as
expected, test2.txt was deleted:
//depot/path/test2.txt#1 - deleted as C:\workspace\depot\path\test2.txt
I am running server 2012.2 and client 2013.1.
Are you doing something that makes the havelist unaware of the files that
aren't being deleted? If the havelist doesn't think they are
depot files, syncing to a label won't delete them as it doesn't think
they are files it has control over. Files that are NOT deleted and
are not in the havelist, will be overwritten by the sync as it needs a place to
write the files, that is if you set your client/workspace to do so. This means
that if you are syncing to a filesystem directory that has files, but the
client/workspace's havelist is unaware of thier state, it will overwrite
existing depot files (files marked add and edit) and will leave non-existent
depot files (files marked delete) alone.
If you're doing something like swapping client specifications over the same
filesystem directory, you might see this behavior as the status of the files in
the filesystem is stored in the client specification, not in the files
themselves. Also some of the offline tools might create a difference
between the filesystem and the workspace's havelist. Streams can
put a different spin on this, but it doesn't sound like you're using
If what I just described is the case, and depending on how your client/workspace
is getting out of sync with the filesystem, there are ways to recover without
too much expense. Post your case and I'm sure we can help you
figure it out.
Also, does your label specification (created with p4 label) cover all the files,
including the deleted files? My specification's label view was
//depot/path/... to cover the entire directory. If your label
specification's view was only something like //depot/path/test1.txt, then it
would miss test2.txt, and the delete would not be labeled when you run labelsync
later or applied when you go to sync to the label.
I'm wondering if you are modifying the label specification in your
automation by looking at the files in the filesystem and using the results to
create the label specification's view. In my scenario above, when
test2.txt is deleted, and if I had used automation to update my label
specification's view to specific files, I would have had
//depot/path/test1.txt and //depot/path/test2.txt in my view, but modified it to
//depot/path/test1.txt only as test2.txt had been
deleted. Unfortunately, when you go to sync, since
//depot/path/test2.txt is no longer in the label specification's view, the
sync process doesn't know to even deal with it, so it will leave the file we
want to be deleted at its last sync'd state.
If this is the case, I'd suggest leaving your label specification's view
as wide as possible using paths with '/...' or '/*', and then
use labelsync and tag to add AND exempt files you DON'T want the label to
know about. Let the sync process handle actually removing deleted
files, not modifications to the label specification. A Label
specification is a control structure. By removing paths and files
from it, you don't remove the paths and files, you remove the control over
them so they'll no longer update when that label is specified.
I'm just taking some wild guesses here, so post with some more details about
the Perforce side of your process if this doesn't help. Details
about your client views and the commands you use in your automation would be
Hope this helps!
Please click here to see the post in its original format:
More information about the perforce-user