Bookmark and Share

Introduction to merging with SVN

Posted: Friday, April 3rd, 2009 at 4:56 pmUpdated: Saturday, April 4th, 2009 at 9:04 am

In previous page, I’ve demonstrated to you the danger of missing a revision copy. The example there is basically pretty straight forward and has small commits that it’s easy to track the commits. Now imagine that you have hundreds of commits. Pretty soon you’ll have repository management issue.

Concepts of merging a branch to another

So on the example we have on page 1 shows that we have to be careful and take into consideration all the previous changes. We also know that we need to apply all the changes when merging so that we can be sure we’re not missing a change-set. Well, one way to ensure that we’re not missing anything is to simply merge all the changes in TRUNK to mine branch. That should take care of it, right ? Well, to some extend. Let’s see how we’ll merge one branch to another.

  1. Since merging requires you to find out from which revision to which revision, we need to first find out what’s the starting revision. We can issue command like below. The last revision being printed would be our starting revision.
    user@dev:~/work$ svn log --verbose --stop-on-copy \
    http://localhost/svn/tutorial/mine/
    --------------------------------------------------------------------
    r3 | user | 2009-04-03 13:10:48 -0700 (Fri, 03 Apr 2009) | 1 line
    Changed paths:
       A /mine (from /TRUNK:2)
    
    Creating my branch
    --------------------------------------------------------------------
    user@dev:~/work$ 
    
  2. Rather than simply copying the head, we can simply merge all the changes from the branch creation to the HEAD revision. So our merge command will be something like below:
    user@dev:~/work/mine$ svn merge -r 3:HEAD \
    http://localhost/svn/tutorial/TRUNK/
    U    testfile.php
    user@dev:~/work/mine$ cat testfile.php 
    <?php
    function my_add($num) {
            $add_by = 5;
            return ($num + $add_by) * -1;
    }
    user@dev:~/work/mine$
    

As you can see from the above, we have all the changes applied to testfile.php. This is good. Now, there’s a caveat though. When you commit the merge to mine branch, you better make sure to remember what revisions were merged before otherwise, when you repeat this process again, you’ll be applying the changes from repository creation again. Most of the time, this would be ok, however, you can’t bet that this will work 100% of the time. There will be times when you’ll have conflicts of the changes.

So now that you know the caveat, there are a few things you can do to get around applying the same changes again and again.

  1. You can manage the merged revision and the commit of the merged changes on a separate database (perhaps a text file, a note on your Outlook, an Excel file, or whatever. That way, the next time you need to merge again, you don’t need to start from repository creation.
  2. When you commit a change, you can have a very specific commit message so that when you do svn log command, you can know that the commit is part of a merge commit. In other words, your own convention on commit message. One example of such message may be including part of the svn merge command as the commit message so that when you do svn log, you can know what was the merge command like “Merged : 3:HEAD http://localhost/svn/tutorial/TRUNK/”
  3. Or you can use a great tool that some smart people have written before: svnmerge.py. What the script does basically is the same as point #2 above, except, it does it automagically.

Alrighty then … so now that we know there’s a great tool to manage merging, let’s look at how to use it on page 3.

Pages: 1 2 3

2 Responses to “Introduction to merging with SVN”

  1. Gabriele Vivinetto Says:

    I think this is not needed woth svn 1.6.x, because it saves merge history in the svn:property mergeinfo.
    Am I wrong ?

  2. Maresa Says:

    Yes … SVN 1.6.x does support merging .. hence we don’t have to use svnmerge.py anymore. There are plenty of cases where distributions doesn’t have SVN 1.6 yet. In particular Ubuntu Hardy (the distribution I’m using). Even if you’re using SVN 1.6, it doesn’t mean that you can’t still use svnmerge.py though. I have a feeling that I would still be using svnmerge.py even though I’m using SVN 1.6 just because I’m already familiar with it. Maybe once svnmerge.py is no longer maintained, I’d be forced to use SVN 1.6 built in merging feature 🙂

Leave a Reply

Time limit is exhausted. Please reload the CAPTCHA.