J. Mash [19/Aug/16 12:24 AM] This should be a blocker rather than critical, as I've just discovered it's causing some downstream CI/CD processes to fail as well -- If this is something that you don't consider a bug, could you please add a configuration option to the repository label step that to handle this case? Perhaps add 'Include Deleted Revisions' option that would make the step use 'p4 tag' instead of 'p4 labelsync', and default it to off (so as to preserve existing functionality)? Thanks, -J. Mash

Robin Shen [19/Aug/16 11:19 PM] I am confused, files in the label should contain exactly the set of files of the view at the time of label. If some files are deleted from the view, the checkout will not see that file and they will also not be included in the label.

J. Mash [19/Aug/16 11:35 PM] Yeah, that's exactly the issue. Consider the following sequence of events:   - Label 'TestLabel1' created using 'p4 labelsync':     - Includes //depot/filea.txt#1     - Includes //depot/fileb.txt#1     - Includes //depot/filec.txt#1   - Developer A syncs to TestLabel1 and gets all three files.   - Developer B deletes a //depot/filea.txt creating revision #2 as a delete.      - Label 'TestLabel2' created using 'p4 labelsync':     - Includes //depot/fileb.txt#1     - Includes //depot/filec.txt#1   - Developer A syncs to TestLabel2 and nothing changes, no files are added, synced, or deleted, despite //depot/filea.txt being deleted from the depot. According to Perforce, they have the latest revisions of all the files listed in the label.   - Label 'TestLabel3' created using 'p4 tag':     - Includes //depot/filea.txt#2     - Includes //depot/fileb.txt#1     - Includes //depot/filec.txt#1      - Developer A syncs to TestLabel3 and //depot/filea.txt is removed from the workspace, because the delete revision is listed in the label. The 'p4 tag' command ensures that delete revisions are also included in the label, where as the 'p4 labelsync' does not. -J. Mash

Robin Shen [21/Aug/16 12:34 AM] Syncing to a label created with labelsync does able to remove deleted files from workspace, at least for Perforce client 2014 on wards. This is how I tested: 1. create a configuration say "root/test1", define a perforce repository to build against a stream say "//streamsDepot/mainline", and add steps to checkout and label 2. now run configuration "root/test1", and a label say "1.0.0" will be created in perfoce 3. create another configuration say "roo/test2", and define the same perforce repository as in step 1 except that the label to checkout is "1.0.0". Add a single checkout step against the depot (do not define label step in this configuration to avoid confusion) 4. run configuration "root/test2", and workspace is populated as in label 1.0.0 5. now delete a file from the depot, and run "root/test1" again, label 1.0.1 will be created 6. edit perforce repository definition of "root/test2" to change build label as "1.0.1". 7. now run "root/test2" again, and examine workspace of "root/test2", the deleted file has also get removed from the workspace If you sync to a QB label with perforce visual client, it also has the option "remove files from workspace if they are not in label" which is checked by default.

J. Mash [21/Aug/16 01:56 AM] That's likely the difference between our two scenarios, yeah. The 'remove files from workspace if they are not in label' is the functional equivalent of doing a 'p4 clean', which has the extremely undesirable effect of removing all files from the local disk that do not exist in the label / workspace. This includes files generated by CMake / PreMake, files generated by the compiler(s) and other tools in the toolchain, and even files that a developer may be working on that have not yet been added and submitted to the depot. This is something that might be situationally acceptable for labels used in CI/CD processes, but is almost never desirable for labels used by developers (in much the same way that 'p4 clean' is also almost never used by developers). This is why the 'p4 tag' command is the generally preferred method for populating a label, but I can understand why it might be problematic to just switch out the 'p4 labelsync' command for a 'p4 tag' command as I had originally suggested. This may be a scenario where it makes more sense to provide an optional setting to allow the 'p4 tag' command to be used instead of the 'p4 labelsync' command (in much the same way that a setting exists to switch between 'p4 sync' and 'p4 clean'). Thanks, -J. Mash

Robin Shen [22/Aug/16 02:18 AM] No at my side, intermediate files will not be removed, only those files in view previously but not in current label will be removed.

J. Mash [22/Aug/16 03:40 AM] Alright, it's clear that the built-in label step will not work for us and there's no desire to provide what will. Please close this. Thanks, -J. Mash