subversion branching perfomance

Question

Hi all,

I want to introduce the following branching model in my project

version1 -> version2 -> version3 -> version4 -> etc.

so 1) There is no trunk 2) Each version is branched from the previous one

Isn't going to be perfomance issue here linked to constantly increasing "branch depth"?

Thanks in advance

Answer 1

No. We regularly do something very much like this. When we deploy a version to production, we make a branch to save the state exactly as it went to production. Then trunk becomes our next regular release. But if, as often happens, there is a bug or some other hot fix, we make a new branch off the production branch. When the next hot fix comes along we make a branch off the previous hot fix branch. Etc. So like, say we have branches/Release-10. Then we have a hot fix, so we copy Release-10 to Release-10-1. If we have another hot fix, we copy Release-10-1 to Release-10-2. Etc. I haven't seen any particular problem with this scheme. (We do have to merge the hot fixes back into trunk, but I'd think with any scheme you'd end up having to do that.)

When you copy a branch, SVN doesn't really copy everything. It just copies pointers. One of SVN's boasts is that the cost of making a branch is very small.

Answer 2

baseline approach is superior to promotion model

I would consider the "Promotion Model" where one version is based directly on its predecessor as an anti-pattern. However it will not create major performance problems. As long as you do not have distinctive parallel development you can live well with it. As well even as with the "standard" baseline model. It worked for me in the past on a pretty linear project.

It will get harder though the longer you need to maintain versions and the more multiple versions you have at your hands. It will require more policies to implement regarding branch stability and desired change propagation resulting in a significant and not necessarily linear increase of management overhead.

You have potentially more merges that are more difficult to track too. Discipline to check in bugfixes only into to the latest version is crucial in your scenario.

Using the branch layout you described, in a big team you could never be absolutely sure you are not leaving a change "behind" that you need in the future as you are constantly cherry picking and your branches never come "together". That is why I like to call it the "error promotion model" whereas in the mainline based approach the worst thing that could happen is a fix is missing in one future version, not in all of them.

Use the baseline approach. It is battle proven and can very well represent the versioning you seem to have in mind. Remember "copy up, merge down" and maybe read up on the "tofu scale" :)

in a nutshell:

trunk
branches
  1
  2
  3
tags
  1.0
  1.1
  1.2
  2.0
  2.1

• develop unstable things in the trunk
• branch from trunk into a maintenance/release-branch ("2" for example)
• stabilize and test it
• create a tag 2.0
• release the tagged code
• commit bugfixes to "2"
• test again
• create tag 2.1
• release tagged code
• merge down ALL changes from "2" to trunk
• merge into "1" if version 1 is still maintained
• tag 1 as 1.2
• release from tag

I recommend this (old) but very valid read: http://www.vance.com/steve/perforce/Branching_Strategies.html