In this section:
Menu commands according to file status
Depending on the file status, the Rollback Changes command will be aliased as shown in the following table:
|File status||Rollback Command||Result|
|modified||all changes made in the file will be reverted, and the file will acquire the up to date status|
|deleted||file will be restored both on the disk and in CVS with the up to date status|
|externally deleted||file will be restored on the disk and assigned the up to date status|
|added||file will be deleted from disk|
|merged||all local changes will be dropped, changes from the repository will be accepted, and the file will be assigned the up to date status|
|merged with conflicts||all local changes will be dropped, changes from the repository will be accepted, and the file will be assigned the up to date status|
|unknown||file will be deleted from the disk|
Effect of rolling back local changes
The effect of Rollback Local Changes may not be what you intuitively expect in terms of the revision you have locally after running the command.
The image below represents a file in CVS and a sequence of actions by two developers. It shows a simple example of what happens in terms of the local copy's CVS revision after rolling back conflicting local changes.
Here's what happens:
- The developer Dev1 takes Revision 1.1 from the repository, modifies it, and commits changes to CVS.
- The developer Dev2 doesn't know about Dev1's changes and modifies the same code in the local copy of Revision 1.1. When Dev2 commits these changes, he gets a message from CVS that the repository has changed. So he runs Update to synchronize, and his local copy is then updated to Revision 1.2, and CVS sets the Merged with Conflicts status on the file.
- Dev2 decides to roll back local changes. He is left with a local copy of Revision 1.2.
- When Dev2 commits the file to CVS, it becomes Revision 1.3 even though the content is identical to Revision 1.2.