Figure 5.11. Update Progress dialog box
Periodically, you shoshould ensure that changes done by others get ininitialized in your local working copy. The process of getting changes from the server to your local copy is knownUpdating. Updating may be done on single files, a set of selected files, or recursively on entire directory hierarchies. to update, select the files and/or directories you want, right click and select tortoisesvn → update in the explorer context menu. A window will pop up displaying the progress of the update as it runs. changes done by others will be merged into your files, keeping any changes you may have done to the same files. the repository isNotAffected by an update.
The progress dialog box uses color code to highlight different update behaviors.
-
Purple
-
The new item has been added to your work copy.
-
Shen Hong
-
Extra items are deleted from your work copy or the items lost in your work copy are replaced.
-
Green
-
The changes in the version library are successfully merged with your local changes.
-
Bright red
-
Modifications from the version library conflict with local modifications and need to be resolved.
-
Black
-
Items in your WC are updated by new versions in the version library.
This is the default color scheme, but you can customize these colors by setting the dialog box. For more information, see the tortoisesvn color settings section.
If you get anyConflictsDuring an update (this can happen if others changed the same lines in the same file as you did and those changes don't match) then the dialog shows those conflicts in red. you can double click on these lines to start the external merge tool to resolve the conflicts.
When the update is complete, the Progress dialog shows a summary of the number of items updated, added, removed, conflicted, etc. below the file list. this summary information can be copied to the clipboard usingCTRL + c.
The Standard update command has no options and just updates your working copy to the head revision of the repository, which is the most common use case. if you want more control over the update process, you should use tortoisesvn → update to revision... instead. this allows you to update your working copy to a specific revision, not only to the most recent one. suppose your working copy is at revision 100, but you want it to reflect the State which it had in revision 50-then simply update to revision 50. in the same dialog You can also chooseDepthAt which to update the current folder. the terms used are described in the "Detection Depth" section. the default depth is working copy, which preserves the existing depth setting. you can also choose whether to ignore any external projects in the update (I. e. projects referenced usingsvn:externals
).
Be careful
If you update a file or folder to a specific revision, you shocould not make changes to those files. You will get "out of date" error messages when you try to commit them! If you want to undo changes to a file and start afresh from an earlier revision, You Can rollback to a previous revision from the revision log dialog. take a look at "roll back (UNDO) revisions in the repository" Section for further instructions, and alternative methods.
Updating to a version is useful when you occasionally want to see what your project looks like at some point in the past. But it is usually not a good idea to update a single file to a previous version, because it will make your working copy inconsistent. If the name of the file you want to update has been changed, you may even find that the file disappears from your working copy, because the file with the name does not exist in earlier versions. If you simply want a local copy of an old version file, you 'd better right-click the file's log dialog box and choose Save version.
Multi-file/folder
If you select multiple files and folders in the resource manager and then select update, these files/folders will be updated one by one. Tortoisesvn ensures that all files/folders from the same version library are updated to the same version! Even if another commit occurs during the update process.
The local file already exists.
Sometimes, when you try to update the file, the update fails, prompting that a local file with the same name already exists. Generally, when subversion tries to detect a new controlled file, it finds that an uncontrolled file of the same name already exists in the working path. Subversion will never overwrite an uncontrolled file-because it may have something you need, it happens to be named again with the file submitted by another developer.
If you get this error message, the solution is to rename the local uncontrolled file. After the update is completed, check whether the renamed file is required.
If you keep getting errors, use tortoisesvn → check the modifications to list all problematic files. In this way, you can solve them all at once.