tags:

views:

623

answers:

4

We are using feature branches in Subversion for our development which is a very convenient way of keeping code within version control that is not yet ready for the mainline. However, whenever I go to merge the feature branch revision into the mainline it is a pain. Right now I go through the following steps:

  1. Check out the original feature branch revision to a new directory
  2. Perform a difference between my current development and the original feature branch directories with a tool like Beyond Compare
  3. Check out the current mainline revision to a new directory
  4. Merge the new/changed files into the current mainline directory.
  5. Perform a difference using my IDE to ensure all of the files are properly checked out/added to subversion
  6. Compile and test
  7. Commit

It seems to me that there is a lot of room for errors in this process and it makes me nervous every time I walk through the steps. Granted, everything is checked into Subversion on my feature branch, so a mistake at any step is recoverable.

I believe that Subversion 1.5 has a way to merge a branch into the mainline, but we are still using Subversion 1.4. What are other people using to simplify the steps of merging a feature branch in Subversion into their mainline development? Are you using different tools? Are you utilizing the merging feature in Subversion 1.5?

+3  A: 

Step 1, 2, 4 and 5 are built into subversion, the command 'svn merge' does it. On your working copy of the mainline type 'svn merge -r startrev:lastref svn://repository/branchurl'. Startref and lastref will be denote the revision-window, that should be merged into the mainline. 'svn://repository/branchurl' should be the URL of your branch.

Subversion 1.5 brings better support for this feature. You no longer need to specify the revisions you want to merge, as subversion now keeps information about merges and simply merge all revision not already merged.

Read more about it in the Subversion-book.

Mnementh
+5  A: 

I am using the new --reintegrate feature of Subversion 1.5 at the moment and I think it's amazing. It's much easier and much less error-prone than the manual way. The downside is, however, that the new merge features require both the repository and the client to be on 1.5 and the changes to the 1.5 repository preclude use by any clients other than 1.5... so to get the merge feature, it's basically an all-or-nothing scenario.

As to your original questions, you just need to keep very rigorous track of which main branch revisions you've merged into your working branch during development. Even with the --reintegrate feature of 1.5, however, it's still important to ensure that the reintegrated working copy of the main branch looks correct and compiles before you commit. It just basically makes life a lot easier (especially for longer-lived feature branches) because you don't have to keep rigorous logs as to what you've changed and when you've integrated changes from other branches to your feature branch.

The release notes documentation at subversion.tigris.org is very well written and I would recommend looking it over briefly to see all the changes between 1.4 and 1.5 and for a good description on the new merging facilities.

Jason Coco
Dan
It's really worthwhile going to 1.5, the capabilities that merge tracking enables are well worth the effort.
Jim T
Now you might as well go to 1.6 though, of course :)
Jason Coco
+2  A: 

If it's your branch you want to merge back to the mainline branch (i.e. you're not an integrator who does that for other developers), here's what you need to do:

  • Write down the revision at which you last merged the mainline into your branch (to keep it in sync). Let's call it "LASTSYNC"
  • check out the mainline branch into a new directory (like MergeFeatureBranchToTrunk), build it
  • in that branch, use svn merge "LASTSYNC":HEAD svn://path/to/FeatureBranch .
  • resolve conflicts (if any)
  • compile
  • test
  • check your changes with a diff tool to make sure everything looks good
  • commit back to mainline
Carl Seleborg
A: 

Have a look at svnmerge; it keeps track of the "what have I merged? what have I chosen to not merge?" part of the job for you, and relies on svn's "merge" command to do the heavy lifting.

introp