Helix Core — version control from Perforce — tracks, manages, and secures changes to all your digital assets, including large binary files. Scale your infrastructure, support your remote teams, and move faster.

 

TRY HELIX CORE FREE

 

Full Video Transcript

When you rollback a file or codeline, you essentially revert the file or files in a codeline to a previous point in time by copying the specified file revision back to the head of the codeline without regard for any modifications that have taken place since the chosen revision.

As you can see from the graphic, when rolling back to the revision submitted in changelist 644, the changes submitted in changelists 645 and 646 are no longer part of the file at the head of the codeline.

You can rollback to a point in time based on revision number, changelist number, date, or label.

To rollback a file or folder to a previous revision using P4V, context click on the file or folder and select the Rollback menu option.

From the rollback dialog, configure the rollback options and identify the changelist where you want the rollback saved.

When you rollback a file or folder, Perforce copies the chosen revision to your workspace and adds the change information to a pending changelist.

When you submit the changelist, Perforce persists the chosen revision to the depot as the head revision.

When you back out a change in a file or codeline, you remove the changes that were part of a submitted changelist while keeping all subsequent changes intact.

To back out the most recent changelist, simply rollback to the previous revision.

Backing out file edits for a revision earlier than the most recent revision is a bit more complex and might involve a series of resolve operations starting with the file or folder version preceding the version with the changes you want to back out through the most recent version. Remember that all resolve operations take place in your local workspace and involve a 3-way merge between the "Base", “Theirs”, and “Yours” files.

In the simplest case, where the differences between the change you want to remove and the file at the head of the codeline are easily identified, you can perform a single three-way merge between the "Base", the version with the bad change, and the head of the codeline.

If the changes made in the series of files submitted after the bad change are more complex, you might have to back the changes out sequentially across each version since the version with the bad change.

We'll illustrate backing out changes in a single file in this discussion. We'll refer to the version with the changes you want to remove as version n.

To start the process, you sync to the revision preceding the version with the changes you want to back out, version n-1, to retrieve a copy of that file into your workspace. You then sync to the version with the changes you want to back out, version n, and Perforce schedules a resolve between the two files as illustrated in the workspace area. In this first case, you choose the Accept yours resolve option which effectively moves your "Base" up to the next version, version n, while keeping the version without the bad changes in your workspace.

Next, you sync again, but this time to the version immediately after the version with the changes you want to back out, version n+1. Version n+1 now becomes the "Theirs" file and Perforce schedules a new resolve between this next set of files. Looking at the files in the merge tool you identify the bad changes as the elements in the "Base" that are not in the "Yours" file and ignore them as you add the changes associated with changelist 645 to the file in your workspace. When you submit this new file, you move your "Base" up to the next version, version n+1, while again keeping the version without the bad changes in your workspace.

As you iterate through the remaining files in sequence, remember that the elements you want to remove will be the elements that are in the "Base" but are not in the current "Yours" file.

In this example, you'd perform one more sync/resolve operation to retrieve the changes from changelist 646 into the file in your workspace. Submitting this final set of edits will effectively back out the changes associated with changelist 644 from the codeline.

The process for backing out changes to a codeline involving multiple files is a bit more complex only because there are more files and changes that have to be resolved at each step. However, the basic process is the same as we've illustrated for a single file.

Backing out file deletions or additions performed when a changelist was originally submitted simply involves adding back deleted files or deleting added files.

As a user you cannot simply delete a changelist from the metadata and remove the associated changes to the versioned files from the depot. A Perforce Administrator can permanently remove files from the depot and associated history from the Perforce metadata but this really defeats the reason for using a version control system in the first place.

Course - Using the Helix Visual Client - P4V