Subversion is quite good about merging changes when two team members simultaneously edit a file. But occassionally two team members will edit the same section of the same file. Subversion isn’t “smart” enough to decide which person wrote the best code (or text, or whatever). Rather than throw out one of the changes, Subversion will report a conflict and store enough information in your working directory to allow you to resolve the problem in one of several ways.
This document describes what Subversion does when it detects a conflict and gives four different strategies for resolving the conflict.
Suppose Sally and Joe are teammates and they are both working independently on their tasks from their last team meeting. Sally and Joe both update their working copy of the team project. Sally adds a new method to a class. At the same time Joe updates the javadoc comment for a different method in the same class.
Now suppose Joe finishes his task first and commits his changes to the repository. Now the base version that Sally is working with doesn’t include Joe’s changes. When Sally finishes her task and attempts to commit her changes, she’ll receive an error message that her version is probably out-of-date. Sally then will do a Subversion update on the file to get Joe’s changes.
In our example, Sally’s and Joe’s changes are independent, so Subversion will merge Joe’s changes with Sally’s. Now the file in Sally’s working directory contains both of their changes. Sally can commit her version to the repository. If Joe does a Subversion update, now he’ll also have his changes and Sally’s.
But suppose Sally and Joe both edited the
same
method. When Sally first tried to commit her changes she would receive the
probably out-of-date
error message. When she then ran a Subversion
update, Subversion would be unable to merge the changes, since it wouldn't know whose change was the “correct” one. In this case, Subversion would report that
one or more files are in a conflicted state. In this case, Subversion will place four files in the directory where the conflicted file was. Suppose the conflicted file was called
SomeClass.java. The four files would be:
SomeClass.java
– this file would include Joe’s changes and Sally’s changes. For each place where they both made changes Subversion will insert text like
<<<<<<< .mine, followed by Sally’s changes, followed by the text
=======, followed by the changes that Joe committed to the repository, followed by
>>>>>>> .r123.
SomeClass.java.mine
– this file would include just Sally’s changes
SomeClass.java.rN, where
N
is some number – this file would be the version that Sally started with, without her or Joe’s changes
SomeClass.java.rM, where
M
is some number greater than
N
– this file would include just Joe’s changes
Sally would change
SomeClass.java
to incorporate the changes in whatever way seems best. This might involve consultation with Joe to see what he thinks or to clarify what changes he made and why. Sally could edit
SomeClass.java
directly to combine the marked changes and delete the
<<<<<<< .mine,
=======, and
>>>>>>> .r123
markers. Sally and Joe might agree that they were both trying to make the same changes and that Sally’s version is better. In that cases, Sally could copy
SomeClass.java.mine
over the top of
SomeClass.java, throwing out Joe’s changes. On the other hand, if they agree to just use Joe’s version, Sally could copy
SomeClass.java.rM
over the top of
SomeClass.java. Finally, if they decided to throw out all the changes, Sally could copy
SomeClass.java.rN
over the top of
SomeClass.java.
After resolving the conflicted files using the above techniques, Sally must right-click on
SomeClass.java
and tell Subversion that the conflict is
resolved. Subversion will delete the extra files that it created when the conflict was detected. Finally, Sally must
commit
the file
SomeClass.java
to the repository so that Joe and her other teammates can get the current version.