Subversion Version Control. Using The Subversion Version Control System in Development Projects

4.10. Handling Conflicts

Let's finish this chapter by taking a look at conflicts and how you can resolve them when they occur. Conflicts occur when Subversion is unable to merge two files together automatically. Generally, this happens when two users have independently made a change to the same area of a file. Because Subversion doesn't actually understand the files that it merges, it has no way of figuring out which of the two versions to use. Its only recourse, in this case, is to let the user solve the conflict.

Before you can resolve a conflict, you have to have a conflict. So, let's create a conflict. To start, check out a new working copy, which will represent the work of a second developer.

$ svn checkout file:///home/bill/my_repository/trunk/ /home/bill/other_dev_trunk A other_dev_trunk/hello.c A other_dev_trunk/Makefile Checked out revision 7.

Then, edit the file hello.c in your new working copy, and change the line

printf{"Subversion Rocks!!\n");

so that it reads

printf("Subversion is Great!!\n");

After the change has been made, commit it to the repository.

[View full width]

With your changes from the new working copy committed, it's time to go back to your original working copy. Once there, edit the copy of the file hello.c that is stored there, without updating the file from the repository first. This time, change the line

printf("Subversion Rocks!!\n");

to the third, yet equally complimentary line,

printf("Subversion is Awesome!!\n");

Now, try to commit this change to hello.c.

$ svn commit --message "Decided on a more hip phrase" /home/bill/my_repos_trunk/hello.c Sending my_repos/trunk/hello.c svn: Commit failed (details follow): svn: Out of date: '/my_repos_trunk/hello.c' in transaction '9'

Well, Subversion obviously didn't like that. The reason, of course, is that Subversion won't allow you to commit changes to a file if those changes cause a conflict with previous changes, which can happen if you try to commit without first updating the working copy to the latest revision. To resolve the conflict, you first need to update your working copy to the latest revision, using svn update.

$ cd ~/my_repos_trunk/ $ svn update C my_repos_trunk/hello.c Updated to revision 8.

Notice that there is a C in front of the listing for hello.c instead of the normal U for files that have been updated. The C is used to indicate a conflict. When a conflict such as this one occurs, Subversion does two things. First, it marks the file as being in a conflicted state. Second, it creates four versions of the conflicted file, for you to use when resolving the conflict.

$ ls trunk/ Makefile hello.c hello.c.mine hello.c.r7 hello.c.r8

The first file, named hello.c just like the original, contains the file with each conflicted area showing both possible versions of the file. The first version shown is the version in your working copy, before the conflict occurred, and begins at a «««<. The second version shown is from the version of the file that the working copy was being merged with. It begins at the ======= that separates the two versions, and ends at a »»»>. You can see an example of this diff view here.

#include <stdio.h> int main(int argc, char** argv) { <<<<<<< .mine printf("Subversion Is Great!!\n"); ======= printf("Subversion Is Awesome!!\n"); >>>>>>> .r8 printf("Copyright 2004, Bill Nagel\n"); return 0; }

The second version of the file, hello.c.mine, is a copy of the file as it existed in your working directory right before the conflict. The third version, hello.c.r7, is the file as it existed in your working directory the last time you checked it out, prior to any local changes. The .r7 tells you that the file is taken from revision 6 of the repository. The fourth and final file, hello.c.r8, is the file as it exists in the repository revision that is being merged into the working directory. Like the previous file, the .r8 extension on this file tells you that it is from revision 8 of the repository.

To resolve the conflict, you need to modify the original file (hello.c in this case) so that it represents the resolved, final version of the file that you would like to commit to the repository as part of the next revision. In doing so, you are free to make use of any of the conflict files Subversion provides (either by copying information from them or copying the file on top of the existing version wholesale), as well as any data from other sources, as necessary. If you need to, to resolve a conflict, you could even rewrite the entire file from scratch.

After you have the conflicted file set up the way you want it, with all conflicting data merged or removed, you need to tell Subversion that you are done. This is done through the svn resolved command, which tells Subversion to remove the flag that marks the file as conflicted. Subversion also removes the extra versions of the file that it created when the resolved command is run. After the conflict has been marked resolved, you are free to commit the file to the repository.^[3]

^[3] Of course, it's entirely possible that someone else may have committed yet another version of the file while you were working on resolving the conflict, which could put the file into a conflicted state again.

$ svn resolved hello.c Resolved conflicted state of 'hello.c' $ svn commit --message "Resolved conflicted state" Sending trunk/hello.c Transmitting file data . Committed revision 9.