Use Subversion Without Trunk

Question

My team recently decided not to use the "trunk" branch that is typical of most subversion repository layouts. We found that at any given moment there was always a particular branch that functioned in the traditional role that trunk would hold in other repositories. That is, we always have a highest-numbered branch that represents the next release that we are working on. Therefore a merge to trunk is simply superfluous, so we got rid of trunk.

Does anyone else out there do this?

If so, have you noticed any pros/cons?

Even if your team does not do this, does anyone have any thoughts on this layout?

Answer 1

Subversion allows both approaches. The trunk is not a necessity but a convention. If you have it, some tools work more easily (for example migration tools for Git). If you don't have it, you must do some things manually but I can't think of something that you'll notice during your everyday work.

Answer 2

We do - sort of. We don't use a trunk, but create a new branch for each release of our projects. This 'tagged' branch is then the trunk for each version, and we backport bugfixes by merging changes onto the older releases.

It works well for us, but we do have a lot of subprojects in our project.

Answer 3

You're talking about the the Promotional Model - Perforce's paper highlights the problems with it - communicating the changing roles of code-lines and moving work between branches.

An expansion on my views of the problems listed:

1) Changing policy of code-lines:

Every code line has a policy, whether it's written down and formalised, or entirely implicit in a developer's head. It defines e.g:

• who is allowed to commit to the code line
• how much testing is required (e.g. do the unit tests have to pass, regression tests, full system test)
• how many people have to code review changes
• what kind of changes are allowed

With the trunk approach, the policies remain fixed, so are easier to write down, which makes them easier to communicate (more important in a larger team).

e.g. Trunk:

• any developer can commit
• any change
• unit tests must pass
• code review after commit

Version branch:

• only maintenance developer
• only bug fix
• unit test + regression tests
• code review by 2 other developer before commit

Tag branch:

• no commits after creation

Developer's private branch:

• Only the developer checks in
• Any change
• Testing only needed before merging to trunk
• Code review before merge to trunk

If you have the promotion model, then you have one policy while in main development, then have to tell everyone when you change policy while preparing for release, then another policy (for the code line) once the line is released.

The promotion model is an easy one to get into, it maps directly onto the non-source control way of working. But it hurts once you start getting large teams.

If you look at the Linux kernel development you can see the strain between the Promotional model and the Trunk model: Linus' tree is Promotional - it goes through cycles between the merge window, and the rc/stabilisation period. But Linux-next and -mm have sprung up to give a more trunk like line.

Distributed SCM/VCS are somewhat different anyway, the policies don't have to be distributed to all developers because each develop has his own trees, and pulls changes when he wants.

Open-source projects suffer from the problem that they can't force people to do the drudge work of stabilising a release, after branching from trunk. Therefore the promotion model is more important as a way of forcing stabilisation efforts, rather than just working on features.

2) Moving work:

A developer might be working on a feature when the policy for the line he's working on changes to bug-fixes only, he now needs to switch his working copy to a different code-line. This may be anywhere from easy to extremely difficult depending on the SCM system in use. This problem doesn't happen if the developer is working on trunk, as their work is always going to trunk. If the developer is on a private or feature branch then their work will only impinge on trunk (and the release) at all.

If a feature is already checked in, but gets delayed from the version it's currently in, you have to work out how to remove it. This problem still existing with the trunk model, but might be a little easier to solve - cherry-picking things from trunk for the release. This is where feature branches help - but they have an integration cost.

Answer 4

I recently started work on a project that is on a subversion repository. Whoever created the repository did not follow any particular layout -- they simply stuffed everything in the root of the repository (no trunk/, no branches/, and certainly no tags/). I wanted to create a branch to work on and some tags for other stuff, but realised how difficult it is to do that on a subversion repository that does not follow a proper layout.

Answer 5

IME, in some environments the trunk is a good place to swap fixes and changes to/from. That is, everybody merges their fixes to the trunk, and everybody merges others' fixes from the trunk. We found that very helpful in an environment where lots of code was shared among many independent projects and where all those projects contributed to the shared code.

You environment might differ, though.

Answer 6

My problem with the Perforce paper is that it rebuffs the promotional model without mentioning the main advantage, reduced merging overhead. In fact, the paper erroneously states that the "mainline model" imposes "no additional administrative overhead", a ridiculuous claim. The "always merge to trunk" model means just that - you have the overhead of everyone having to merge. This is pointless overhead if you have the following situation (which we have):

a) a small team (5 to 7 developers) all within shouting distance of each other. communication is a non-issue when we need to make a branch

and

b) a codebase where there is ever really only 2 major branches - a production branch and "the next thing in development". Maybe once in a blue moon we have 3.

I guess my point is -- it's a situational thing. To say the "promotional model has problems" is like saying "never use an OR/M". It depends on your environment.