Can I safely edit a renamed file in perforce

Question

I have a file I need to move that's already under perforce. Once moved it needs some editing - update the package, etc - appropriate to its new location. Should I submit the move changespec and then reopen it for edit, or can I do this in one go? If so, what is the appropriate sequence of events?

Answer 1

"Safely" is probably an important point here. Once you rename or move the file it'll get a revision number of "1" which looks like a new file to your Perforce client. Of course, admins will be able to get its prior history, but if the editing/version history of the file is important to you it's a little harder to get the older revision.

Update: Thanks to Commodore Jaeger and Greg Whitfield for enlightening comments.

This wasn't easy to track down regarding what the One True Answer is, even from Perforce support, so I figured I'd update everyone on what we found:

• Perforce stores all versions of every document in its database.
• If it's saving your file as type <text> or <ktext> then it stores the diffs of one file version to another and not the entire file.
• If you check out a file, make no changes to it, and then re-submit, it will save as a new version with 0 diffs. This is configurable and P4 can be set up to ignore changelist items without any actual diffs. You can force this behavior by selecting "Revert unchanged files..." before you submit a changelist.
• Use "Rename/Move..." to move files in P4 so it can track them. Don't copy them using Windows Explorer and then re-add them in P4.
• If you use the "Rename/Move..." function from the context menu, the "new" file will show a revision number of "1" as though it were a new file.
• However, since P4 saves every function performed on a file, you can actually get to any previous revision (and even recover "deleted" files) with the CLI command p4 filelog -i
• If you want to get to the revision history of a moved or renamed file and you're not an admin, you can right-click and select its "Revision Graph" which shows every version of a file even when moved between branches.

According to Perforce support, easier tracking of revision history through branch or folder moves is an oft-requested feature and is in their current roadmap.

Perforce's answer: At the moment, there isn't a way to move/rename/integrate files and still maintain the exact file history.

However, if you were to choose "Integrate..." by right-clicking on the folder that you want to share, the versions of the files of the newly branched folder and underlying files will start from revision #1, but the integration history between the branched folder and underlying files and the original folder and underlying files will remain through which you can trace the revision history of the files.

Answer 2

I would say always submit first then edit. It is much cleaner and makes it more obvious whats happening in your repository. Then simply checkout the file in the new location and make whatever changes. This also makes it much more obvious that the changes were made in the new location and to all it to work after renaming.

Answer 3

I have done this before in one go, but depending on your build process, I recommend against it. What I generally do is this:

1. Move the file.
2. If the move needs a change in order to compile, open it for edit and make those changes.
3. Submit the changes, telling perforce to reopen the files for editing.
4. Make the changes for path, etc., that don't cause compile errors but should be updated.
5. Submit those changes with an appropriate description.

If you want to, however, you could just do all your changes in step (2) above. Perforce might change the flag for the new file from integrate to add, but it still remembers the source path for the file.

Edit: Better method

I realized that I often use a different method, but the idea of "moving" the file distracted me. So, I would recommend these steps instead:

1. Integrate the file into the new path/name, leaving the previous file there. I am assuming that this won't break your build process.
2. Submit the new file, checking it out again for edit after submission.
3. Make the required changes to the new file, and to the project so that you are using the new file.
4. Submit the edits for the new file.
5. [Optional] You might need to check through branch specs to see if you need to map the old file into the new one in any branches.
6. Create a changelist for deleting the old file, and submit it sometime later.

This method allows the edits to be cleanly separated from the rename/move, while never leaving the project in a state that won't compile.

Also, why wait for step 6? Sometimes, especially on bigger projects, you might want to move a file that another person is editing. Perforce will helpfully tell you this. By waiting to delete the file, you allow your coworker(s) to finish the edits and submit without needing to move their work manually. After the edits are submitted, they can be integrated into the new file, and then the old one can be safely deleted.

Answer 4

Yes you can. Simply reopen for edit the branched file (i.e. the new one). In P4Win, there is a context menu for this ("re-open for edit").

Answer 5

Submit the move change and then reopen for edit (you could use the reopen option too). This is much more readable to the user in the change history.

Also, recent versions of Perforce do perform checks for changes to files after resolution. So, there may be complaints editing files after some resolve operations have been completed.