Version Control with SVN - Conflicts

In the last article, we learned about some basic operations in SVN. These helped us take the theoretic knowledge from the first article in the series and turn it into something practical. We learned about check out, which takes the code from our repository and pulls it to our local machine. We also learned how to use update to pull changes from the repo to our computer. Also, how to use diff to see the changes and how do to check in, in order to push the changes to the repo. Finally, we learned how to create new branches. In this article, we'll learn about merging and conflicts.

What happens if I leave the trunk and go to a branch called develop. Say I changed a file called file1.php. While I'm furiously working away on my branch, another programmer changed the same file in the trunk. In SVN I'll have a problem when I try to merge my branch with the trunk. The file I'm trying to merge has been changed by another programmer!

This diagram will shed some light on the problem:

SVN is smart enough to know that the file called file1.php has been changed in the trunk. A situation in which I try to make changes to a file that has since been changed on a different branch is called a conflict. Normally, if the changes were made to different parts of the file—for instance one programmer changed lines 1-5 and another lines 20-30—there won't be a conflict. SVN knows how to merge the two files so that my changes and the changes from the other programmer will be included. But if we both made changes to lines 1-5, then we really have a conflict.

In this situation, human intervention is required by one of the programmers in order to reconcile the conflict. Is my change more important, or is the other programmer's? Or should we rewrite the file so that it has both changes included? This is called resolving conflicts, and when working in a team, it happens a lot. The most important thing is to be careful and not to erase any of the changes from another programmer, who’s then likely to enact revenge later on.

So how does this look in real life? As soon as I try to merge changes in the trunk, I'll have a conflict and I'll need to change the code. Then I'll need to push again to version control.

Imagine I have a project that looks like this:

.

├── branches

│   └── develop

│       └── index.php

└── trunk

   └── index.php



3 directories, 2 files

Someone changed Index.php in the trunk, and I changed it in develop. I want to return develop to branch. First I need to make sure that all the remote changes were pulled to my branch. I run the merge command like so:

$ svn merge http://localhost/svn/testrepo/trunk/

Notice that in this case, the URL of the repo is of my repository. If you're working with a repository of SVN, you probably have a different URL.

As soon as I launch this command, SVN warns that I have a conflict and asks what to do.

I can view the difference between the files (diff), go straight in to edit mode, erase the changes and get the remote version, or get just my version. I’ll ask to view the changes first. Here’s what I get:

--- index.php.working - MINE
+++ index.php - MERGED
@@ -1,6 +1,10 @@
< ?php

//Printing Hello World!
+<<<<<<< .working
print "Hello World???";
+=======
+print "Hello World!!!!";
+>>>>>>> .merge-right.r8

Spot the conflict? In our example, we have my version called working which is the local version. What’s written? Hello World with question marks. In the remote version, the trunk, Hello World is with exclamation points.

After this, I still need to decide what to do. In this case, I’ll choose to start the merge process. In the merge, I’ll need to make tough decisions related to the code itself. Do I need to take your changes first? Or take mine before yours?

Merging 'index.php'.
Conflicting section found during merge:
(1) their version (at line 4)                                    |(2) your version (at line 4) 
-----------------------------------------------------------------+-----------------------------------------------------------------
print "Hello World!!!!";                                         |print "Hello World???"; 
-----------------------------------------------------------------+-----------------------------------------------------------------
Select: (1) use their version, (2) use your version,
       (12) their version first, then yours,
       (21) your version first, then theirs,
       (e1) edit their version and use the result,
       (e2) edit your version and use the result,
       (eb) edit both versions and use the result,
       (p) postpone this conflicting section leaving conflict markers,
       (a) abort file merge and return to main menu:

Here it depends on the code. In any case, after the decision, I’m asked again if there’s anything I need to do. If I’ve edited the fixed everything I can mark the conflicts as resolved:

Merge of 'index.php' completed.
Select: (p) postpone, (df) show diff, (e) edit file, (m) merge,
       (r) mark resolved, (mc) my side of conflict,
       (tc) their side of conflict, (s) show all options: r

After the conflicts have been resolved, I need to do check in to push the new version to the trunk. Now I can do the merge. I go to the trunk, run update just to be safe, and then pull the develop branch with this command:

svn merge --reintegrate http://localhost/svn/testrepo/branches/develop

We learned a few important concepts here:

Conflict - what happens when there is a change in the same place in the same file on two different branches at different times. Conflicts must be resolved by a person.

The resolution is whatever the developer decides to do with the code. There are many ways to resolve conflicts. But once the conflict has been resolved, you must tell SVN with mark resolved.

We also saw that diff is a very important part of the conflict process.

Next time, we’ll talk about additional tools in SVN that will help us see the real power of this version control software.

About the author: Ran Bar-Zik is an experienced web developer whose personal blog, Internet Israel, features articles and guides on Node.js, MongoDB, Git, SASS, jQuery, HTML 5, MySQL, and more. Translation of the original article by Aaron Raizen.