I've started to use Subversion with TortoiseSVN. If I open up the log and right click on an old revision I see two options that sound like they roll back to an older version: "Update item to revision" and "Revert to this revision".
I understand that updating to an older revision is used when you only want to look back at an old version but not really change the repository. Revert is when you actually screwed up and want the latest revision in the repository to be the same as an older version.
So say the HEAD revision is 100 and I revert back to 95. It will reverse merge my working copy back to 95. Then I can commit that change to the repository which would create revision 101 correct? How is that different if I were to update back to revision 95? Doesn't it still just reverse the changes from the last revisions? I'm confused as to how the state of my working copy differs after a Reverting or Updating to an older revision.
This question is related to
svn
tortoisesvn
The files in your working copy might look exactly the same after, but they are still very different actions -- the repository is in a completely different state, and you will have different options available to you after reverting than "updating" to an old revision.
Briefly, "update to" only affects your working copy, but "reverse merge and commit" will affect the repository.
If you "update" to an old revision, then the repository has not changed: in your example, the HEAD revision is still 100. You don't have to commit anything, since you are just messing around with your working copy. If you make modifications to your working copy and try to commit, you will be told that your working copy is out-of-date, and you will need to update before you can commit. If someone else working on the same repository performs an "update", or if you check out a second working copy, it will be r100.
However, if you "reverse merge" to an old revision, then your working copy is still based on the HEAD (assuming you are up-to-date) -- but you are creating a new revision to supersede the unwanted changes. You have to commit these changes, since you are changing the repository. Once done, any updates or new working copies based on the HEAD will show r101, with the contents you just committed.
The text from the Tortoise reference:
Update item to revision Update your working copy to the selected revision. Useful if you want to have your working copy reflect a time in the past, or if there have been further commits to the repository and you want to update your working copy one step at a time. It is best to update a whole directory in your working copy, not just one file, otherwise your working copy could be inconsistent.
If you want to undo an earlier change permanently, use Revert to this revision instead.
Revert to this revision Revert to an earlier revision. If you have made several changes, and then decide that you really want to go back to how things were in revision N, this is the command you need. The changes are undone in your working copy so this operation does not affect the repository until you commit the changes. Note that this will undo all changes made after the selected revision, replacing the file/folder with the earlier version.
If your working copy is in an unmodified state, after you perform this action your working copy will show as modified. If you already have local changes, this command will merge the undo changes into your working copy.
What is happening internally is that Subversion performs a reverse merge of all the changes made after the selected revision, undoing the effect of those previous commits.
If after performing this action you decide that you want to undo the undo and get your working copy back to its previous unmodified state, you should use TortoiseSVN ? Revert from within Windows Explorer, which will discard the local modifications made by this reverse merge action.
If you simply want to see what a file or folder looked like at an earlier revision, use Update to revision or Save revision as... instead.
Update your working copy to the selected revision. Useful if you want to have your working copy reflect a time in the past, or if there have been further commits to the repository and you want to update your working copy one step at a time. It is best to update a whole directory in your working copy, not just one file, otherwise your working copy could be inconsistent. This is used to test a specific rev purpose, if your test has done, you can use this command to test another rev or use SVN Update to get HEAD
If you want to undo an earlier change permanently, use Revert to this revision instead.
-- from TSVN help doc
If you Update your working copy to an earlier rev, this is only affect your own working copy, after you do some change, and want to commit, you will fail,TSVN will alert you to update your WC to latest revision first If you Revert to a rev, you can commit to repository.everyone will back to the rev after they do an update.
@BaltoStar update to revision syntax:
http://svnbook.red-bean.com/en/1.6/svn.ref.svn.c.update.html
svn update -r30
Where 30 is revision number. Hope this help!
To understand how the state of your working copy is different in both scenarios, you must understand the concept of the BASE revision:
BASE
The revision number of an item in a working copy. If the item has been locally modified, this refers to the way the item appears without those local modifications.
Your working copy contains a snapshot of each file (hidden in a .svn folder) in this BASE revision, meaning as it was when last retrieved from the repository. This explains why working copies take 2x the space and how it is possible that you can examine and even revert local modifications without a network connection.
Update item to Revision changes this base revision, making BASE out of date. When you try to commit local modifications, SVN will notice that your BASE does not match the repository HEAD. The commit will be refused until you do an update (and possibly a merge) to fix this.
Revert to revision does not change BASE. It is conceptually almost the same as manually editing the file to match an earlier revision.
Source: Stackoverflow.com