Perforce Public Knowledge Base - How To Rollback An Integration
Downloads Blog Company Integrations Careers Contact Try Free
Menu Search
Reset Search



How To Rollback An Integration

« Go Back



How do I undo mistakes in integration?
How do I rollback an unintended integrate?


When you are undoing a mistaken integration, the first thing to check is whether or not the integrate has been submitted.

Pending Integration

If the integration has not been submitted with p4 submit, then the pending integration can simply be reverted. For example:

p4 revert //depot/path/to/file 

Submitted Integration

There are three methods for rolling back submitted integrations:

  • Use p4 obliterate to permanently remove file revisions introduced by the problem changelist from your version history.  Note, this option requires "superuser" access to Perforce database which might seem a bit excessive. Just remember: removing existing records from Perforce database is a serious job not intended for a "standard" Perforce user.
  • Edit the target files at revisions just prior to the integrate and then use p4 resolve to merge out the problem changelist. The idea behind this method is to overwrite  the #head revisions produced by a "bad" integrate with an older revisions of the same files that you can trust.

  • Beginning with the 2008.2 release of P4V, use the Rollback feature to rollback to a changelist, date/time, label, or specific file revision.

When rolling back a submitted integration, it is important to consider whether or not the target files have subsequently been edited. If the target files were not edited after the problem integrate, then using p4 obliterate is the cleanest and fastest approach. If the target files were edited after the problem integrate, then using the sync/edit/resolve approach or P4V is preferable.

Each approach to rolling back submitted integrations has limitations.

For cases where target files were edited after submitting the problem changelist, the p4 obliterate approach removes the problem integrate transaction records, but it does not remove associated file content. In other words, any content merged in the problem integrate is retained in later versions of the file.

By contrast, when using the sync/edit/resolve approach, or P4V, the problem content can be backed out of the file; however, the prior "bad" integration history remains intact. In other words, you still receive integration credit for the problem integrate; if you want to revisit that integrate, you might have to use the -f flag to force the re-integration of certain revisions. See the Command Reference for details on p4 integrate syntax.

Method 1: Obliterate (no subsequent edits)

When you use the obliterate command, you should proceed with caution. Be sure that you are using the appropriate command syntax and have good backups.

  1. Perform a checkpoint and backup on your database, if necessary.

    For information on checkpoints and backups refer to: The Perforce System Administrator's Guide


  2. Verify that there have been no additional changes by typing:

    p4 filelog //path/filename

    You might want to verify the correct versions to be removed by viewing the file history with the Revision Graph tool in P4V or P4Win. If there have been edits, consider using Method #2 below to back out the problem integration.

  3. When you have identified the versions that need to be removed, issue the following obliterate command for each file version that you want to correct. For example:

    p4 obliterate //path/filename#4

    Without the -y flag, p4 obliterate runs in "report-only" mode.

  4. Carefully examine the output of the preceding p4 obliterate command that shows the list of files and revisions to be permanently removed. If the output looks OK, add the -y flag so the command actually performs the obliterate. For example:

    p4 obliterate -y //path/filename#4

    All affected file versions are removed permanently.

    NOTE: Make sure that each filespec in the obliterate command has a revision number. If not, all history of the given file is lost. In the example above, only revision #4 of "filename" is destroyed. Also, make sure there is no space between the file name and the revision specifier (#4); otherwise, the file and the revision specifier will be interpreted as separate arguments. Lastly, the (#4) can be always replaced
    by @change,change, for example:

    p4 obliterate //path/filename@bad_change,bad_change


Once you are satisfied that you have successfully obliterated the problem revision(s), you can revisit your intended integrate command.

Method 2: Sync, Edit, Resolve

This approach to backing out a submitted changelist is discussed in KB Article #14. As with the case of rolling back an edit, you sync to the revision prior to the problem change, edit the file, resolve the file, and then submit. Rolling back an integration differs from the edit case in that there is integration history that is not "undone" by this method.

Method 3: P4V features

Beginning with the 2008.2 release, P4V lets you rollback the files contained in a changelist by choosing Back Out from the menu displayed when context-clicking on individual changelists. Or choose Rollback from the menu displayed when context-clicking on files or folders to rollback to a revision, changelist, or label (or date/time, for files only).

Related Links



Was this article helpful?



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

Characters Remaining: 255