Posts Tagged ‘ SVN ’

SVN Merge Without Conflicts

The Problem

 I had created a branch and wanted to merge changes from the original trunk into that branch, bringing it up to date. Sounds simple enough, just right click on the branch folder and (with tortoise svn) click on Merge. 

 Then keeping all of the wizards default, go through and Merge. Easy!

Except when I do it this way I get a conflict for every file that has changed. Even if it was changed in the trunk but not in the branch, or changed in the branch but not in the trunk. I can’t work with that because then every time I want to merge I’d have to manually resolve conflicts on potentially hundreds of files.

mergeconflict3

I must be doing something wrong…

Setting Up The Branch

So lets go back a few steps to setting up the branch.

1. Create an empty folder, I called mine MergeTestBranch.
2. Checkout from the trunk.

checkoutsvn

3. Now create a branch, don’t forget to check the ‘switch working copy to new branch’ box.

 createbranch

Make Some File Changes

Ok so now we have a branch and currently it is an exact copy of the orginal trunk. This is the contents of the directory: filelist1

 

 

 

So now to recreate the merge conflict ‘problem’ what we need to do is:

  1. Change a file in the branch. I just added the word, ‘branch’ to the bottom of fileTwo.txt.
  2. Change a file in the trunk. I just added the word, ‘trunk’ to the bottom of fileThree.txt.
  3. Change a file in both the trunk and the branch. I just added the word, ‘trunk’ to the BOTTOM of fileFive.txt and added the word, ‘branch’ to the TOP of fileFive.txt.
  4. Save the changes.
  5. Commit the changes to the trunk, and commit the changes to the branch.

Before you try to merge…

…make sure your working copy of the branch is “clean”—that it has no local modifications reported (from SVN Book)

In other words, if you are using tortoise SVN, make sure you have the ‘green tick’.

Doing the Merge – Incorrectly

So now if we repeat the merge that I mentioned at the start of this post, i.e. from the trunk into the branches working directory, keeping all of the merge wizard defaults, you get the merge results shown in the first image of this post. 

As you can see, the three files that we changed are all conflicted. Not what you want!

Doing the Merge – Correctly

Of course SVN is doing what it should, the problem is how I am doing the merge. The way to make this work as I want it to (no conflicts for the files we changed) is actually very easy.

1. Before starting the merge, right click on the branch working folder and select Show log.

showlog

2. Why are we looking at the log? We need to know the original revison number that this branch was created from. Write down the revision number (in this case 29635)

getrevisionnumber

3. Start the merge in the usual way, keep ‘Merge a range of revisions’ selected and click next.

4. Now the important bit. What we need to do differently is tell SVN the revision range to merge.

mergerevisionrange

 So what we are doing here is telling SVN, I want you to merge changes from the trunk starting from revision number 29635 and going up to the HEAD (doesn’t need to be the head, can be another revision number…of course).

Or in other words, grab all of the changes that have been made in the trunk since I created my branch…and merge those changes into my working copy.

 

 

 

 5. Click Next, test the merge and you should now get this result

mergenoconflicts1 

Much better!

Of course you will still get conflicts, but only when SVN is unable to automatically resolve it, e.g line 5 of a file was changed in the trunk and the branch.

And finally, automatic resolution of conflicts makes life alot easier when merging but remember that there’s no way SVN can detect symantic differences in your code so occassionally the auto merge will merge correctly in terms of file differences but may cause problems in the code’s logic…though in my experience this is very rare. How do you cater for this problem though? Simple, write unit tests 🙂 and make sure you have a Continuous Integration server setup!

Happy merging!

VSS to SVN Migration

Subversion

This post has a few tips and insights from my recent experience of migrating from VSS to Subversion.

The first thing to note is that version control in SVN has some conceptual differences to VSS and it is worth spending some time reading the SVN Book to understand these differences. Understanding these differences will often give you the ‘why’ for migrating to SVN.

Why did we migrate?

Our shortlist of reasons for migrating:

  1. Branching in SVN is much easier than VSS.
  2. VSS doesn’t always play nicely when disconnected (issues with working folders)
  3. With SVN I can work on n individual bugs in completely separate folders, allowing me to easily work on the bugs independantly (useful for example if you are say writing a new feature against the dev source and urgently need to fix a bug in the production source). Once again VSS has ‘working folder’ issues when you work this way.
  4. Depending on where you store your repository, SVN plays nicely over the internet…fantastic for teams working remotely.

History

If you can migrate without keeping the history then that is the easiest and fastest way.It’s not ideal but you can always still get the history of a file from VSS.

Note:  easiest != best.

If you want to maintain history I used this migration tool with great success.

A few things about the migration tool…

  1. Play with it on a mini repository first! (and remember it changes your system clock!)
  2. The most time consuming part of the process is when it does a ‘get history’ from VSS. Drove me nuts because you get the history with the VSS gui and you get the results almost immediately, get the history from the cmd line and it took 40-60 seconds! I did search for some cmd line switch to help but no joy.
  3. It’s c++ so I was too scared to make any changes and it worked fine but the source is available if you need to tweak it.
  4. I had some corruptions in VSS, this causes the migration tool to pause. Make a note of the file, ignore and continue.
  5. Depending on the size of your repo you may want to import from a logical sub project.

You will also need to do the migration on a separate dedicated machine because it changes the system clock when committing. So yes the migration tool must run on the same box as the repository it is committing to. Once the migration is complete you can either copy your flashy new SVN repo to it’s new ‘production’ home or if you have set it up with a Berkely DB then you’ll need to export and import. The SVN Book has plenty of details on ‘how’ to export/import etc.

This blog entry helped me as well.

When You are Done

Test

I strongly recommend you run the app through a full test phase once you are done to ensure you ‘got everything’.

Point to the New Location

If you have a CI server setup you’ll need to configure to point to the new repo, same goes for you and your team members.

Maybe change the location of the old VSS repo so that no one accidentally checks in. Don’t delete it though.