Conflict Resolution

Subversion is pretty smart about merging changes. But what happens if two people make incompatible changes to the same part of the file at the same time?

Let's demonstrate. We'll update both working copies to the most recent revision, then make different changes to each copy of Combinatorics.java, but on the same line. We update/commit one copy, and it's fine. But when we update/commit the second copy, we get a conflict warning!

We have to resolve this conflict before we can commit our changes. To help us, SVN has left us lots of notes:

• Combinatorics.java.mine is a copy of the file as we had it just before the update.
• Combinatorics.java.rOLD is a copy of the file at the revision that we started working with. (That is, the second most recent update.)
• Combinatorics.java.rNEW is a copy of the file at the revision that we just pulled down with the update command.
• Combinatorics.java is the working copy of the file, annotated with conflict markers.

If we open Combinatorics.java in an editor, we can see the conflict markers. Let's resolve the conflict, save the file, and commit.

But the commit fails! We have to tell SVN that we've resolved the conflict:

$$\mbox{\texttt{svn resolved Combinatorics.java}}$$

This cleans up the notes that SVN created for us and lets SVN know that we've resolved the conflict. Now, we can commit the changed file.

SVN's notion of conflicts only goes so far, though. It doesn't know anything about what the contents of the file mean; it only knows which lines have changed. So, let's have our first programmer edit Combinatorics.java to change the type of the fact method to use an accumulator; it now takes two arguments.

While we're doing this, our second developer decides to add a new function, perms, that computes ${}_nP_r$; this will of course use fact. Since we're working from an old version, we give it a single argument. When we update, SVN doesn't tell us anything about a conflict, even though the resulting code clearly won't compile.

So, here's the process:

1. Edit.
2. svn update
3. Resolve any conflicts.
4. Try to compile the code; fix any problems. You may even want to run test cases here.
5. Commit. (Of course, someone else may have committed while you were fixing problems. In that case, you'll get an out-of-date error, so start again from step 2.)