2
votes

I recently had to backout a submitted changelist (CL#926201) after discovering that there were runtime conflicts with another project.

After backing out the changelist I synced to the changelist which I had previously submitted by using (from the root of my workspace):

p4 sync ...@926201

This downloaded the old revisions of my changed files to the workspace, but did not add them to a pending changelist.

I wanted the files from my original changelist to be added to a new changelist so that I could resubmit them after investigating the issue locally and making any necessary revisions.

I couldn't find any commands which would accomplish this for me, but I did reconcile the changed files in my workspace which were not added to any changelists in my workspace by using (from the root of my workspace):

p4 reconcile

This turned out to be a mistake. The command took about an hour to run, and ended up adding every artifact from every target directory from every project I'd ever run out of that workspace. I ended up with a 52,000 file changelist. Perforce dutifully checked out all of these files from the depot for me which took another hour or so to undo.

At this point I decided to manually add only the files which I'd modified in CL#926201 to the new changelist. This took a while longer, but I eventually got everything to match up with how it was before the original submission of CL#926201.

In case I'd made a mistake in this process I decided to sync with the depot again in order to ensure that the differences were exactly the ones which I wanted to keep. I used IntelliJ for this, which I assume is calling some flavor of p4 sync internally (I do know that the force flag was off since there's an option for this in the IntelliJ GUI). I expected there to be merge conflicts (or whatever Perforce calls them) that would allow me to simply accept all of the local revisions. Unfortunately all of the files in my new changelist were immediately reverted to the backout revision. I suspect that retrieving a particular revision from before had somehow flagged these files as "okay to overwrite these because they're old". I don't know the specifics, but I'm curious to find out.

Now that I was back at square one I decided to give up on using Perforce directly and ended up manually copying all of the file diffs into the existing classes line by line so that they'd look like new changes to Perforce when I eventually went to submit them. This was a tedious process and I felt rather stupid having to do it this way, but it ultimately worked.

Now I'm left wondering how I was supposed to go about this. It seems like a fairly common use case, but I can't find any mention of the correct approach for getting your changes back and resubmitting them after a backout. What should I have done here instead?

1
To control what reconcile does and doesn't process, use P4IGNORE.Bryan Pendleton
For more details on reconcile: answers.perforce.com/articles/KB/3481Bryan Pendleton
For backing out a slightly older changelist and moving it to a separate branch, try: answers.perforce.com/articles/KB/5357/…Bryan Pendleton
The sync flag which authorizes sync to overwrite your local edits is '-f'. The 'clobber/noclobber' option in your client spec also affects this.Bryan Pendleton
And for general suggestions on backing out submitted changelists, try: answers.perforce.com/articles/KB/3474/…Bryan Pendleton

1 Answers

3
votes

Keep in mind that restoring a backed out changelist is really just another case of backing out a changelist (you're backing out the backout), so everything I'm about to say pertains to backing out changelists generally rather than to "resubmitting" a backed out changelist specifically. :)

If you're aiming to just put everything under the current directory back to the state it was in as of change 926201, here's one really simple option:

p4 copy ...@926201 ...

This will open the files, so you can look at the resulting changelist/diffs/etc before submitting.

If you were to use reconcile to do this, the sequence of steps would be more like:

p4 sync ...@926201
p4 sync -k ...
p4 reconcile ...

The trick there is that you want to tell the server that you're operating on the files relative to the head revision even though the actual contents of your workspace are @926201 -- that's where the "sync -k" comes in (incrementing the have rev to the head rev while keeping your physical workspace contents).

For more complex variations that predate "p4 copy" and "p4 reconcile", see this Perforce KB article: http://answers.perforce.com/articles/KB/3474/?q=backout+a+changelist&l=en_US&fs=RelatedArticle

From your description of doing the "sync" from IntelliJ it sounds like a "revert" might have been involved behind the scenes -- once a file is opened with "p4 edit" or "p4 reconcile", a "p4 sync" absolutely won't touch it, even with the "-f" option. At most it will schedule a "p4 resolve" (which will then update/overwrite/merge/keep the contents according to the resolve option selected).