In many instances, changes made to a working copy file may not be suitable for committing to the repository.
This may be the case with modifications made for the sake of testing. Or you may have decided on an alternative course of action and wish to start over. Or perhaps you have realized that you have insufficient time available to complete the changes you have started.
Whatever the reason, Subversion allows you to roll back any changes made to files under version control by reverting the file back to the initial state it had after the last commit or update (which is known as the file’s BASE revision).
Reverting a File or Folder to BASE
To revert a modified file to a pristine copy of its BASE revision:
Select the files or folders in the working copy browser which you wish to revert. Use the Command (⌘) and Shift (⇧) keys to select multiple items.
Select Working Copy > Revert to Last Update… (key equivalent ⌘L) or click Revert in the app’s toolbar.
Once reverted, all modifications made to your working copy files will be irrevocably lost.
Cornerstone therefore prompts you to confirm that the files should be reverted before continuing.
Click Copy to Trash First to make a backup copy in the Trash if you think you may need the modified files in the future.
Click Discard Changes to revert the selected files without making a backup first.
Files which scheduled to be added, moved or copied at the next commit are reverted to their previous unversioned status.
Files scheduled for deletion are undeleted and restored to the working copy.
The revert function will also discard changes to a file or folder’s Subversion properties.
Reverting to an Arbitrary Revision
In some situations it may be necessary to undo committed changes and roll back to a previous revision of the file.
While Subversion specifically only supports reverting files back to their BASE revision, Cornerstone extends Subversion’s revert functionality to also allow you to revert a file back to any previous revision.
To roll back to a previous revision:
Select the files or folders in the working copy browser which you wish to revert. Use the Command (⌘) and Shift (⇧) keys to select multiple items.
Select Working Copy > Revert...
The revision sheet is displayed.
Specify the number of the revision to revert to in the Revision field. You may also specify a date or select a revision from the picker.
Click the Revert button.
If the selected files contain local modifications then Cornerstone will ask whether the modifications should be kept or discarded.
Select Discard Changes to discard local modifications before reverting to the selected revision.
Selecting Copy to Trash will discard the local modifications before reverting but only after placing a copy of the modified files in the Trash.
Selecting Keep Changes will cause the local modifications to be preserved and merged with the differences between the current and selected revisions.
Note that local modifications may cause conflicts with differences between the current and selected revisions, so it is normally best to discard changes (copying them to the trash if necessary) before reverting.
When reverting, the differences between the current and selected revision are merged (or reverse-merged to be precise) into the selected working copy items. These changes are like any other working copy modifications and can be reviewed and edited as required before being committed to the repository.
In fact, if you are not happy with the results of the revert then you can undo them by reverting the working copy items back to their BASE revision (but note that any local modifications made prior to the original revert will be lost.)
Before reverting to a previous revision, it is generally best to:
Remove or commit all local modifications.
Update the working copy to the latest revision.
Updating the working copy is particularly important as it ensures that a consistent working copy state is used as the basis of the reverse merge.
Reverting a mixed-revision working copy can result in differences not being consistently applied across the working copy.
For example, If a working copy is at revision 541 but contains newer modifications up to 545 then reverting to 540 will only reverse merge the changes between 540 and 541 into the working copy, and not all changes between 545 and 540.
Updating the working before reverting will bring the working copy up to revision 545 therefore ensuring that all changes will be correctly reverted to 540.
in the app’s toolbar.