Working on a large project with others can be difficult to coordinate. When each user is working on a set of files for some task, sooner or later users will try to commit the same file in two different versions. This is called a conflict.
This guide will demonstrate the basic steps you can take to resolve a conflict once it has happened. We deal with three solution strategies:
Theirs - choosing to accept all incoming changes and discarding all your own changes to a conflicting file.
Mine - the opposite of theirs, discarding all changes done by other users to a file since you last updated it from the server.
Manual/merge - the most time consuming, but by far also most effective strategy. You must manually go through the different versions of conflicting files and assemble a new file from the changes to commit. This is easier than it sounds, although it does require some work.
If conflicts arise, Kdesvn will silently create three files in the same folder as the conflicting file. In the example, the file README has been changed locally, and an update was attempted before committing the changed file. However, someone else has already modified the file, causing the conflict.
README,mine is the local file with uncommitted changes.
README.r14 is the new version with conflicting changes.
README.r15 is the original version before the conflicting version.
README is now a file with attempted automatic merges and annotations from Subversion.
The simplest way to merge files in these scenarios is using Kdesvn and Kdiff3 - the latter is a merge tool available in most distributions.
Opening the repository in Kdesvn will highlight conflict files in the main file view (top-right). Right click the conflicting file and click Resolve conflict from the menu.
|Overview of files. Note the highlighted line with a conflicting file.||
Right-clicking the conflict file allows you to mark it resolved (if you merged it externally) or to resolve it now.
When kdiff3 opens a small dialog box will give you a status of the conflict. Many conflicts can be solved automatically. These are conflicts where only one of the new versions have performed modifications - in these cases, the automatic merge will simply defer to the newer content, assuming the user who did not modify those parts would agree.
The remaining conflicts consist of new changes in both versions. For each conflict you must decide either to use your own version of that change, the other user's version, or create a completely new compromise manually.
Click OK to continue to the merge window.
Kdiff3's main window is split into four parts. The three top frames contain (from left to right) the original file, your version and the new version from the server. The bottom frame contains an overview of all conflicts and how they have been resolved so far.
In this example, the local user removed the first phrase of the file together with several small changes, while the second user chose to split the single-line text into lines of at most 80 columns of characters (a somewhat standard text width). Subversion is only capable of performing automatic merges on entire lines. Thus, Subversion "sees" that the original and local files consist of one file each, which are different from each other and the new version, while the latter contains three lines of text. Since the two "new" lines have no priors, they are automatically carried on into the merged version. This is denoted in the lower frame's left column by the C character. This means that the version from file C (right-most) is used; a theirs strategy.
However, the first line cannot be automatically merged, denoted by the question mark in the bottom frame's left column. Right-clicking its line allows you to perform a merge. You can choose any combination of the three versions of the line. In this example, we decide to work with the new version instead of trying manual consolidation. To use all changes from the new version, go to Merge in the top menu and click on Choose C Everywhere. This tells kdiff3 to use the new version everywhere (as in a complete theirs merge). You could also use Choose C for All Unsolved Conflicts to only use C's version in the remainder of conflicts. In this example, they accomplish the same.
A final conflict is a line ending type conflict. This is due to the file being edited in two different operating systems; the local file was edited in Linux, which uses so-called LF for a newline. The new version was made in Windows, where LF+CR is used. We recommend that collaborators agree on a single line ending style (configurable in most text editors) - the specific choice, however, is largely academic. Click the dropdown labeled Line end style and pick Unix. Finally, close kdiff3 and choose to save before closing.
Back in Kdesvn, right-click the conflicted file and click Mark Resolved. You should commit the file immediately to ensure a new conflict does not arise in the meantime.