SVN Merging – Proper Sequence of Actions

branchingmergingprogramming practicessvnversion control

I'm totally new to CVCS (SVN specifically). I find that most resources focus very strongly on the command-line commands (irrelevant; we use Windows Explorer + TortoiseSVN) and about structure (e.g. projects inside our outside TTB, etc). Here's a thing about merging I'm not sure of:

Based on my sandbox testing, I got the understanding that merging should be done sort-of backwards? I first thought that merging meant going from the branch into the trunk, but it now seems to me that I should actually merge the trunk into my branch, fix conflicts there, and only then commit my branch into trunk?

Let's say I'm responsible for merging a branch into the mainline, and everybody has committed their local changes into that branch. I now switch my working copy to the branch and merge the trunk into my working copy in order to resolve any conflicts locally and tidy things up. When complete, I commit my working copy into the trunk (there should be none or hardly any conflicts in this step).
This is basically also what one needs to do when committing changes from one's working copy into the branch.

Right? Wrong? Am I missing some steps? It seems complicated but makes sense.

_{Let's not argue about how merging in SVN is harder than in DVCS's because that's not something I can change.

Also, I'm not asking about the specific command-line actions because we're using TortoiseSVN.}

Best Answer

Yes, that is a best practice for how SVN is designed. You have your branch, you merge the trunk into your branch, because there are always issues to deal with (it is easier if you periodically do this while working on your branch), and when it's good you merge it back into the trunk. At this point there shouldn't be any conflicts unless someone else has come and checked in updates in between.

It does seem complicated but after doing it a few times it becomes easier.

Related Solutions

Version Control – Creating a Version Control Strategy for SVN

If you want a unified build process, then be sure to put branches/tags/trunk at the root, like this:

branches/
tags/
trunk/
  dev/
    ...

If you don't need a unified build process, then you can put branches/tags/trunks within each project if you want. However, it might be difficult to migrate to a unified build after having put them within each project. A unified build has advantages, such as eliminating the need to publish shared components among projects -- they're all part of the build.

Personally, I like a unified build process. Furthermore, I don't think you should have a "dev" project. You should have projects directly under trunk, and then branch trunk into a dev branch. Use tags for releases. For example, I would do it like this:

branches/
  dev/
    Site1/
    Site2/
    WebService/
    SharedCode/
tags/
  release1/
    Site1/
    Site2/
    WebService/
    SharedCode/
trunk/
  Site1/
  Site2/
  WebService/
  SharedCode/

Version Control – Is Mercurial a Better Choice Than SVN?

Yes.

If you replace "SVN" with "Perforce" in your OP you've pretty much got the situation I found myself in when I started my current job, even down to the manual-change copying. Two years on we're on Mercurial and everyone agrees it's been a great change.

We have the ability to branch and merge per support case, which is unbelievably useful for QA, and the ability to create any number of throwaway branches and repositories whenever we see fit, which we can then build and verify in our CI server, then deploy to a cloud test environment and verify functionality. This has been of huge benefit in terms of peace of mind that when we do a live deploy, we're almost 100% sure that it will work (sans environment/DB issues, which are obviously out of the scope of the VCS).

Basically, what we gained from switching to mercurial is breathing space. We no longer have to worry about the cost of a branch, or the horrific merge sessions that inevitably used to follow, everything is much much easier. We also use FogBugz quite heavily so the tie-in to Kiln (their hosted mercurial) is really helpful.

The comment about the hginit site is spot on too, as an outline for a version control workflow that actually works (assuming you adjust it for your company's particular QA workflow).

The only possible flaw in moving version controls is that you will need someone who's really a driving force behind the change, who's happy to read up on the subject matter and really use the tooling to the best of its potential, which you seem to want to do.

I don't agree with the comments about team size and team distribution relating to whether to use DCVS either. Really, it's about CODE distribution. If you have multiple development cycles happening in parallel, either support cases on a legacy system, or a bunch of features or even new systems (which by the sound of it you do), you will benefit from using a DVCS.

Related Topic