Perforce Public Knowledge Base - Backing Out Submitted Changelists
× PRODUCTS SOLUTIONS CUSTOMERS LEARN SUPPORT
Downloads Company Partners Careers Contact Free Trials
Menu Search
Perforce
Reset Search
 

 

Article

Backing Out Submitted Changelists

« Go Back

Information

 
Problem

Backing out a changelist that has already been submitted (by overwriting it with previous content).

Solution

Rollback to Revision in P4V

In the 2008.2 and later releases of P4V, a new feature has been added to automatically rollback a changelist. From the release notes:

#160209 *
        A new Rollback to Revision(s) feature has been added and is 
        available for file revisions, submitted changelists, and labels.
        A file deleted at the head revision can be rolled back to the 
        previous revision. Use an empty pending changelist for rollbacks.
        Additionally, a Rollback limited to only the files contained in a
        changelist can be performed by selecting Back Out from the menu
        displayed when context-clicking on individual changelists.
        (Sir #15176, #17520, #31688)

P4 Command Line Client SOLUTION

This section demonstrates three scenarios, starting with the simplest case and ending with the most difficult:

  1. Backing out a very recent changelist (edits only)
  2. Backing out an old changelist (edits only)
  3. Backing out adds and deletes as well as edits

Backing out a very recent changelist (edits only)

In the following example changelist 1000 was submitted by mistake. The description of changelist 1000 shows:

Change 1000 by trudi@spice on 1999/07/27 11:47:04

Revamp web pages.

Affected files ...
... //depot/foo.txt#9 edit
... //depot/bar.txt#3 edit
... //depot/ola.txt#4 edit


In this example changelist 1000 contains edits only -- no files were added or deleted. Also, in this scenario, you just submitted changelist 1000 -- nothing has changed in your workspace since you did the submit, and no one else submitted any subsequent changes to the files in changelist 1000.

To back out changelist 1000:

  1. p4 sync @999
  2. p4 edit //depot/foo.txt //depot/bar.txt //depot/ola.txt
  3. p4 sync
  4. p4 resolve -ay
  5. p4 submit

Below is a more detailed explanation of what these commands do:

  1. Syncs to the last good revisions of files affected by changelist 1000 -- that is, the files as they were before changelist 1000 was submitted.
  2. Opens these files for edit.
  3. Syncs to head revisions. The opened files are not changed, but they are scheduled for resolve.
  4. Resolves the files with "accept yours" so that the workspace file contents are untouched.
  5. Submits the last good revisions as the newest revisions.

Backing out an old changelist (edits only)

In this scenario, changelist 1000 was submitted some time ago. Since the submit other good edits have been submitted to the same files. Backing out changelist 1000 is more complicated in this case because you have to preserve any subsequent changes to the files. In this example changelist 1000 contained file edits only -- no files were added or deleted.

When backing out an old changelist, use a workspace with no opened files. You can use p4 opened to see if there are any opened files in your current workspace. To back out changelist 1000 when subsequent changes have been made to the files you:

  1. p4 sync @999
  2. p4 edit //depot/foo.txt //depot/bar.txt //depot/ola.txt
  3. p4 sync @1000
  4. p4 resolve -ay
  5. p4 sync
  6. p4 resolve
  7. p4 submit

Explanation:

  1. Syncs your workspace to the files at the state they were in before changelist 1000 was submitted.
  2. Opens the files affected by changelist 1000 for edit.
  3. Syncs your workspace to the files at the state they were in as of changelist 1000. The opened files are not modified, but they are scheduled for resolve.
  4. Resolves the files with "accept yours" so that the contents of the opened files are untouched.
  5. Syncs your workspace to the head revisions. The opened files are not modifed, but they are scheduled for resolve again.
  6. Allows you to interactively resolve all changes that occured after changelist 1000 with the opened files you have in your workspace. In other words, you are now merging the good edits back in. Resolve each file with "accept merged". (If there are conflicts, you have to edit the merged results first. Conflicts indicate places where lines modified by changelist 1000 were also modified by subsequent changes.)
  7. Submits the fixed files as the newest versions.

Backing out an old changelist with adds and deletes as well as edits

What do you do if there were added or deleted files in the bad changelist? You submit a new changelist to do the reverse: if a file was added, you delete it; if a file was deleted, you add it. This final scenario assumes changelist 1000 included an add, a delete, and an edit:

Change 1000 by trudi@spice on 1999/07/27 11:47:03
Revamp web pages.
Affected files ...
... //depot/foo.txt#1 add
... //depot/bar.txt#3 delete
... //depot/ola.txt#4 edit

To back out changelist 1000 in this scenario, you use the following steps:

  1. p4 sync @999
  2. p4 edit //depot/ola.txt
  3. p4 add //depot/bar.txt
  4. p4 sync @1000
  5. p4 resolve -ay
  6. p4 sync
  7. p4 resolve
  8. p4 delete //depot/foo.txt
  9. p4 submit

Explanation:

  1. Syncs your workspace to the files at the state they were in before changelist 1000 was submitted.
  2. Opens the edited file for edit.
  3. Opens the deleted file for add.
  4. Syncs your workspace to the files at the state they were in as of changelist 1000. The opened files are not modified. The file that is opened for edit is scheduled for resolve.
  5. Resolves //depot/ola.txt with "accept yours" so that its contents are untouched.
  6. Syncs your workspace to the head revisions. The opened files are not modifed, but they are scheduled for resolve again.
  7. Allows you to interactively resolve all of the changes that were made to //depot/ola.txt after changelist 1000.
  8. Opens changelist 1000's added file for delete.
  9. Submits the fixed files as the newest versions.

If the changelist contains deletes only, then this case reduces to that described in Recovering Deleted Files.

Considerations when integrating backed out changes

When rolling back a changelist that was the result of an integration from another branch, or a changelist that was itself integrated to another branch, keep in mind that your newly submitted "rollback" changelist is treated like any other set of adds, edits, and deletes.

For example, if you roll back an integration and then re-attempt the same integration at a later time, Perforce will report "all revisions already integrated" because the rollback did not have any effect on the integration records. Conversely, integrating your rollback changelist back to the other branch backs out the change in that branch as well. (See Determining Revision to Integrate) If you roll back a change that has been integrated to other branches, subsequent integrations of the rollback change to those other branches also backs out the change in those branches.

After considering how your rollback change is treated by subsequent integrations, you may decide that it makes more sense to back out the change on another branch, or in some cases to roll back the change, integrate the rollback, and then roll back the rollback, restoring the originating branch to its original state. This alternate procedure provides another version of the rolled back change that you can integrate into your branch at a later date, while in the short term allowing you to work in your branch without the presence of that change.

 

For more information about rolling back an integration see How to Rollback an Integration.

Related Links

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255