Do you continue development in a branch or in the trunk? [closed]

Question

I have tried both methods with a large commercial application.

The answer to which method is better is highly dependent on your exact situation, but I will write what my overall experience has shown so far.

The better method overall (in my experience): The trunk should be always stable.

Here are some guidelines and benefits of this method:

• Code each task (or related set of tasks) in its own branch, then you will have the flexibility of when you would like to merge these tasks and perform a release.
• QA should be done on each branch before it is merged to the trunk.
• By doing QA on each individual branch, you will know exactly what caused the bug easier.
• This solution scales to any number of developers.
• This method works since branching is an almost instant operation in SVN.
• Tag each release that you perform.
• You can develop features that you don't plan to release for a while and decide exactly when to merge them.
• For all work you do, you can have the benefit of committing your code. If you work out of the trunk only, you will probably keep your code uncommitted a lot, and hence unprotected and without automatic history.

If you try to do the opposite and do all your development in the trunk you'll have the following issues:

• Constant build problems for daily builds
• Productivity loss when a a developer commits a problem for all other people on the project
• Longer release cycles, because you need to finally get a stable version
• Less stable releases

You simply will not have the flexibility that you need if you try to keep a branch stable and the trunk as the development sandbox. The reason is that you can't pick and chose from the trunk what you want to put in that stable release. It would already be all mixed in together in the trunk.

The one case in particular that I would say to do all development in the trunk, is when you are starting a new project. There may be other cases too depending on your situation.

---

By the way distributed version control systems provide much more flexibility and I highly recommend switching to either hg or git.

I've worked with both techniques and I would say that developing on the trunk and branching off stable points as releases is the best way to go.

Those people above who object saying that you'll have:

• Constant build problems for daily builds
• Productivity loss when a a developer commits a problem for all other people on the project

have probably not used continuous integration techniques.

It's true that if you don't perform several test builds during the day, say once every hour or so, will leave themselves open to these problems which will quickly strangle the pace of development.

Doing several test builds during the day quickly folds in updates to the main code base so that other's can use it and also alerts you during the day if someone has broken the build so that they can fix it before going home.

As pointed out, only finding out about a broken build when the nightly build for running the regression tests fails is sheer folly and will quickly slow things down.

Have a read of Martin Fowler's paper on Continuous Integration. We rolled our own such system for a major project (3,000kSLOC) in about 2,000 lines of Posix sh.

I tend to take the "release branch" approach. The trunk is volatile. Once release time approaches, I'd make a release branch, which I would treat more cautiously. When that's finally done, I'd label/tag the state of the repository so I'd know the "official" released version.

I understand there are other ways to do it - this is just the way I've done it in the past.

Both.

The trunk is used for the majority of development. But it's expected that best efforts will be made to ensure that any check-in to the trunk won't break it. (partially verified by an automated build and test system)

Releases are maintained in their own directory, with only bug fixes being made on them (and then merged into trunk).

Any new feature that is going to leave the trunk in an unstable or non-working state is done in it's own separate branch and then merged into the trunk up on completion.

I like and use the approach described by Henrik Kniberg in Version Control for Multiple Agile Teams. Henrik did a great job at explaining how to handle version control in an agile environment with multiple teams (works for single team in traditional environments too) and there is no point at paraphrasing him so I'll just post the "cheat sheet" (which is self explaining) below:

I like it because:

• It is simple: you can get it from the picture.
• It works (and scales) well without too much merge and conflict troubles.
• You can release "working software" at any time (in the spirit of agile).

And just in case it wasn't explicit enough: development is done in "work branch(es)", the trunk is used for DONE (releasable) code. Check Version Control for Multiple Agile Teams for all the details.

A good reference on a development process that keeps trunk stable and does all work in branches is Divmod's Ultimate Quality Development System. A quick summary:

• All work done must have a ticket associated with it
• A new branch is created for each ticket where the work for that ticket is done
• Changes from that branch are not merged back into the mainline trunk without being reviewed by another project member

They use SVN for this, but this could easily be done with any of the distributed version control systems.