Update the Working Copy
While you are working on a project, other members of your team may be committing changes to the project repository. To get these changes, you have to update your working copy. Updating may be done on single files, a set of selected files, or recursively on entire directory hierarchies. The update operation can be performed from Working Copy view. It updates the selected resources to the last synchronized revision (if remote information is available) or to the HEAD revision of the repository.
There are three different kinds of incoming changes:
- Non-conflicting - A non-conflicting change occurs when a file has been changed remotely but has not been modified locally.
- Conflicting, but auto-mergeable - An auto-mergeable conflicting change occurs when a text file has been changed both remotely and locally (for example, has non-committed local changes) but the changes are on different lines of text. Not applicable to binary resources (for example, multimedia files, PDFs, executable program files)
- Conflicting - A conflicting change occurs when one or more of the same lines of a text file have been changed both remotely and locally.
If the resource contains only incoming changes or the outgoing changes do not intersect with incoming ones then the update will end normally and the Subversion system will merge incoming changes into the local file. In the case of a conflicting situation the update will have as result a file with conflict status.
The Oxygen XML Editor allows you to update your working copy files to a specific revision, not only the most recent one. This can be done by using the Update to revision/depth action from the Working Copy view (All Files view mode) or the Update to revision action from the History view contextual menu.
If you select multiple files and folders and then you perform an Update operation, all of those files and folders are updated one by one. The Subversion client makes sure that all files and folders belonging to the same repository are updated to the exact same revision, even if between those updates another commit occurred.
When the update fails with a message saying that there is already a local file with the same name Subversion tried to check out a newly versioned file, and found that an unversioned file with the same name already exists in your working folder. Subversion will never overwrite an unversioned file unless you specifically do this with an Override and update action. If you get this error message, the solution is simply to rename the local unversioned file. After completing the update, you can check to see if the renamed file is still needed.