| 15.3. Download new versions from the central repository: update | ||
|---|---|---|
 | Chapter 15. The version control system Subversion |  |
| 15.3. Download new versions from the central repository: update | ||
|---|---|---|
| | Chapter 15. The version control system Subversion | |
When sharing files among several users (or there are multiple copies in different machines) it is possible that the server has a version of the files that is more recent than your local copy. In such a case, we want to “update” our copy to contain the changes in the repository. This operation is invoked with the order update as shown in the following example:
svn --username [YOUR_ID] updateThis command must be executed from a directory that contains files managed by Subversion (thus there is no need to specify the repository URL). It is typical to start a working session with this command to make sure we have the latest version of the files in the remote repository. The following figure shows the evolution of the local and remote copies when the update order is applied.
When this command is executed, all files and folders are updated recursively. For each file that is processed (those with no changes are ignored), a character is printed in the first column of the line with the following meaning:
A: “Added”. The file has been added to the remote copy and therefore it has been also added to the local copy.
D: “Deleted”. The file has been deleted in the remote copy, and therefore, it has been delete now in the local copy.
U: “Updated”. The local copy has been updated with a more recent version from the remote repository.
E: “Existed”. There is a new file in the local copy but it has not been added to Subversion. A file with identical name needs to be downloaded from the remote copy. The recommendation is to delete the local copy to allow the remote copy to be downloaded.
G: “Merged”. The remote copy had been changed, and now the local copy reflects these changes as well. But they have been applied on top of additional changes in the local file. The result is a local copy with the changes in the remote copy incorporated, but still locally modified.
C: “Conflict”. Changes are present in both the local and remote copy and they cannot be merged automatically. The local copy is modified to include both versions next to each other and let the user fix it. The file needs to be edited, search for the mark “<<<<<” and mix manually the two versions.
To avoid conflicts derived from merging changes, there are two simple rules that can be used: avoid two people working over the same file at the same time, but if this is not possible, send your changes and update the changes very frequently with respect to the repository to help the system merge the changes automatically. If after the update operation you have files with conflicts, read Section 15.9 to see in detail how to proceed.
| |  | |
| 15.2. Downloading the first copy: checkout |  | 15.4. Sending changes to the central repository: commit |