![]() 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. It is best to update a whole directory in your working copy, not just one file, otherwise your working copy could be inconsistent. 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. Update your working copy to the selected revision. Once done, any updates or new working copies based on the HEAD will show r101, with the contents you just committed. You have to commit these changes, since you are changing the repository. 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. If someone else working on the same repository performs an "update", or if you check out a second working copy, it will be r100. 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. You don't have to commit anything, since you are just messing around with your working copy. If you "update" to an old revision, then the repository has not changed: in your example, the HEAD revision is still 100. 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.īriefly, "update to" only affects your working copy, but "reverse merge and commit" will affect the repository. If you Revert to a rev, you can commit to repository.everyone will back to the rev after they do an update. 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 want to undo an earlier change permanently, use Revert to this revision instead. 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 ![]() It is conceptually almost the same as manually editing the file to match an earlier revision. The commit will be refused until you do an update (and possibly a merge) to fix this. When you try to commit local modifications, SVN will notice that your BASE does not match the repository HEAD. Update item to Revision changes this base revision, making BASE out of date. 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. svn folder) in this BASE revision, meaning as it was when last retrieved from the repository. Your working copy contains a snapshot of each file (hidden in a. The revision number of an item in a working copy. To understand how the state of your working copy is different in both scenarios, you must understand the concept of the BASE revision: The file content of both scenarions is same, however in first case you have an unmodified working copy and you cannot commit your changes(as your workingcopy is not pointing to HEAD rev 100) in second case you have a modified working copy pointing to head and you can continue to work and commit Solution 2 Your working copy is now in modified state. ![]() Revert to this revision will undo all changes in your working copy which were made after the selected revision (in your example rev. Update to revision will only update files of your workingcopy to your choosen revision.īut you cannot continue to work on this revision, as SVN will complain that your workingcopy is out of date.
0 Comments
Leave a Reply. |