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.
Imagine that you have edited a file called FILE and are now trying to perform a commit. A typical conflict would look something like this
svn: Commit failed (details follow):
svn: File or directory 'FILE' is out of date; try updating
svn: The version resource does not correspond to the resource within the transaction. Either the requested version resource is out of date (needs to be updated), or the requested version resource is newer than the transaction root (restart the commit).
The first thing to do now is to try and update the repository again which presents you with the following dialog
Conflict discovered in 'FILE'.
Select: (p) postpone, (df) diff-full, (e) edit,
(mc) mine-conflict, (tc) theirs-conflict,
(s) show all options:
As you can see there are several ways of resolving the conflict. Choose s for an extended view of all the options.
(e) edit - change merged file in an editor
(df) diff-full - show all changes made to merged file
(r) resolved - accept merged version of file
(dc) display-conflict - show all conflicts (ignoring merged version)
(mc) mine-conflict - accept my version for all conflicts (same)
(tc) theirs-conflict - accept their version for all conflicts (same)
(mf) mine-full - accept my version of entire file (even non-conflicts)
(tf) theirs-full - accept their version of entire file (same)
(p) postpone - mark the conflict to be resolved later
(l) launch - launch external tool to resolve conflict
(s) show all - show this list
Choosing e will bring up a text editor for editing the conflicting file. In the editor you will see sections looking like this
The text you wrote.
The text your colleagues wrote.
(Note the colouring is merely for distinguishing these lines and will not be represented in the terminal)
Edit the file and save the changes when you are done. You can now use r to resolve the conflict with the changes you made to the file.
As an alternative you can choose to disregard the changes made by either you or your colleagues. Choose mc to proceed with all the changes from your version or choose tc to proceed with all the changes made by your colleagues.
When you are done commit the changes to make sure that the newest revision is available on the server.