Preventing the Propagation of Deletes

SUMMARY

There are several ways to deal with the problem of maintaining a file in one branch after it is deleted in another branch.


DETAILS

In branches related by integration, if you delete a file(s) in the source branch, subsequent integrations, by default, propagate the delete to the target branch. If you want to maintain an un-deleted file in the target branch, then you must do one of the following:

  • Delete the target file, then re-add it. This "resolves" the integration relationship, and future integrates between branches no longer attempt to propagate the delete.

  • Always integrate by using a branch spec -- and exclude the deleted source files in the branch spec.

  • Open the associated target file(s) for edit using p4 edit. In this case, Perforce refuses to propagate the deletes unless the -d flag is used with p4 integrate. This approach is probably the least desirable.

Each of the above methods has it advantages and disadvantages. The first method is the cleanest, but requires the extra step of re-adding the target file.

The second method is simple and efficient, but it can be difficult to enforce and requires some maintenance. The second method assumes that:

  • You always integrate using a branch spec, and
  • You maintain an updated branch spec that excludes deleted files of interest.
    Example
    To prevent the propagation of "deletedFile1" and "deleteFile2" to the "/main" branch, you could maintain a branch spec such as "Dev2Main" below:
    Branch: Dev2Main
    View:
       //depot/dev/... //depot/main/...
       -//depot/dev/deletedFile1 //depot/main/deletedFile1
       -//depot/dev/deletedFile2 //depot/main/deletedFile2
    
    and use this dev branch spec whenever you integrate between these branches:
    p4 integ -b Dev2Main
    
    Each time a deleted file appears in one branch that you do not want in the other, you can add another exclusionary mapping to the branch spec.

The third method is not really recommended, but can be used for quick results. First, this method is inelegant in that files are not being opened for edit, but as an artifact of preventing deletions. Second, it can be difficult to track which files are open for preventing deletions, and which files are open for real editing work. Third, if you use the -d flag when integrating, it renders this method ineffective.