UC3M

Let us suppose that in the Subversion repository there is an initial version of a file which we will call version A. A member of the team makes some changes in an area of that file and sends the changes to the repository with the commit. This new version will be called version B of the file. At the same time, in your local copy, which is identical to version A of the remote repository, you make some changes on the same area of the same file. When these changes are sent to the repository, the operation marks the file with the letter “C”, a conflict has appeared (see Section 15.4). Subversion has tried to merge the changes that produced version B with your changes but it was not possible. The file is modified and left for you to solve this merge. The following figure illustrates this situation.

Let us assume that the file in which the conflict appears is called writenumbers.c. After obtaining version C (local copy with changes) and send the changes to the repository with the commit we are informed that the file needs to be updated. When executing the update command the conflict appears and we are given several options. We type the letter “p” to postpone the solution. If we check the status of the file with the status command, we can see the conflict. Furthermore, in the directory, three new files have appeared: writenumbers.c.mine, and to more files with a suffix that starts with “r” followed by a number (the version number). The following figure shows this situation.

The file writenumbers.c.mine contains the version with your local changes (that is, version C), and the two files with the suffix “r” followed by a number are versions A and B in the remote repository. The file with a lower version number is the older.

The program kdiff3 is an editor prepared to merge the content of these three versions in a final one. The program is invoked as follows:

kdiff3 writenumbers.c.mine writenumbers.c.r151 writenumbers.c.r153 -o writenumbers.c

The command receives as arguments the name of the three files (versions A, B and C) and with the option -o we select the file where to store the result. The editor shows in three windows the three files and in the bottom part the resulting file. The following figure shows the tool editing this conflict.

With the arrows in the upper part, you may move among the different conflicts (in this case, there is only one). For each conflict you may select the content of any of the three versions (buttons A, B and C) to be included in the resulting file, or directly write the correct text in this file. Upon termination, the file is saved and the tool terminated. After this operation, the status of the file still appears with conflict. This is because Subversion requires an explicit confirmation that a file no longer has conflicts using the resolved command as shown in the following example:

svn resolved writenumbers.c

After this command, the file is ready to be sent to the remote repository with the commit command.