Proper sequence of actions for merging using SVN?

Question

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.}

Answer 1

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.

Answer 2

Before asking about merging, you should ask whether you need branch-based development.

The answer depends solely on your project and team. I personally believe in branches for application-level "feature" development, but am comfortable with changing trunk/master for utility projects and new development (bugfixes to released projects require branches, but that's a separate topic, and is motivated by different concerns).

If you're going with a branch-based development style, then it becomes imperative that the branches do not diverge too far from the trunk. That leads to merge pain (even with a DVCS), but more important, it means that your feature is developed without consideration for what's happening elsewhere.

The solution is simple: regular merges of the trunk into all outstanding branches. As I describe it, "changes get pushed upstream (from branch to trunk) but flow back downstream (from trunk to branches)." If you have multiple people on the team working on different features, I believe that every developer should merge the trunk into his/her feature branch whenever the trunk is updated (ie, whenever another feature is complete).

Answer 3

What you are looking for is likely an accumulation branch.

If you have just two branches - the development branch and mainline, and main line has changed since the development branch was made and merges from mainline to the development branch wasn't done during the process:

+------.----.------dev-------------------------...
   /     /     /                                 
  /     /     /                                  
+------------------mainline--------------------+

Then its just a 'simple' matter of doing another merge from the mainline to dev, fixing up the merge in dev, and then merging back to mainline (which should have had minimal changes between the two merges) and closing the branch.

+------.-----.-----dev---.-----.+
   /     /     /             /   \               
  /     /     /             /     \              
+------------------mainline--------------------+

The key here is that you really should avoid having a broken build from mainline. Mainline is in most places a 'this is good' and what people branch from. If you instead did just a 'merge to mainline and fix':

+-----.-----.------dev----+
   /     /     /           \         finally fixed            
  /     /     /             \        v            
+------------------mainline--.---.---.---------+

It is possible that the someone could have branched from the broken state in mainline during before those were ready and stable. This is often seen as a bad thing.

One of the bits with this that can cause some issue is that after development is done on the dev branch, its role/policy changes. Development happens in a dev branch... but after development is done, you're doing something else in the dev branch. This goes against some patterns of branching. You may not use this pattern, but its something to be aware of and consider.

---

The above case was the simple one - one dev branch. But what if you have two dev branches that need to be reconciled?

I point to Advanced SCM Branching Strategies by Stephen Vance (a really good read when it comes to branching and central version control style systems (rather than distributed - though if you read it you can certainly find parallels between this document and things like git flow).

Vance identifies specific roles that a branch can be. You've got mainline, development, maintenance, accumulation, and packaging. In this case, we're dealing with mainline, dev, and ultimately accumulation.

The problem with working with two branches and trying to do the merge into the mainline is that it can make it even more of a mess for a longer period of time.

The solution is to introduce an accumulation branch.

In the previous example, accumulation role was also part of the mainline branch (which has the mainline role too). It looked like this:

But, when things get hairy with merges, having the mainline and accumulation roles both on the mainline branch can lead to issues. So instead, create an accumulation branch to which you merge the development branches which can then be reconciled there and merged back into the mainline. This particular image also shows a packaging branch, but thats not at issue here.

One important bit to note here is that everything branches from mainline (not some other branch), has a life cycle, merges back into mainline, and then is closed. There are no long running branches (other than mainline). Each branch has a specific role to fulfill and when that is complete the branch is removed.

Answer 4

This might be because I cut my teeth on SVN but we handle big DCVS merges the same way. Moreover most open source projects I see encourage you to follow a similar pattern with pull requests -- don't send one until you've made your patches work with the latest and greatest.

So I'm not sure if this is limited to SVN but yeah, the practice you describe in your question isn't merging backwards and it really is a better approach when there are multiple hands in the repo.