Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

If we only work with one branch in Subversion, should we even bother? Can't we just work on the trunk to speed things up?

This is how we develop with Subversion:

  • There is a trunk
  • We make a new development branch
  • We develop a new feature on that branch
  • When the feature is done, it is merged in the trunk, the branch is removed and a new development branch is made from the trunk

When we want to release to production, we make a tag from the trunk. Bugfixes are made on a branch from that tag. This bugfix is then merged in the trunk.

This is why we make a new development branch after a feature is done. This way, the bugfix is included soon enough in our new code.

Below is a diagram which should clarify:

Our Subversion strategy

Now, there's a feeling this isn't the most efficient way of working. We build locally before we commit, which takes about 5-10 minutes. You can understand that this is experienced as quite a long waiting time.

The idea of a development branch is that the trunk is always release-ready. But this isn't true in our situation anymore. Sometimes, a feature is almost ready, and some developers will already start coding the next feature (otherwise, they would be sitting around waiting for one or two developers to finish and merge).

Then, when feature 1 is finished, it is merged into the trunk, but with some commits of feature 2 included.

So, should we even bother with the development branch, as we only ever have one branch? I've been reading about trunk-based development and branch-by-abstraction, but most articles I've found focus on the branch-by-abstraction part. I get the impression that's for big changes that will span over several releases. This is not a problem we're having.

What do you think? Can we just work on the trunk? Worst-case scenario is (I think) that we would have to make a tag from the trunk and cherry-pick the commits we need, because some commits/features aren't production ready yet.

share|improve this question
1  
I think it would be better if you had more than one branch. One for each feature. This way, if you ever do start working on a large feature that will take a bit of time, you will not hold up bug fixes and such for already released versions. –  Amy Anuszewski Jul 6 '11 at 15:40
    
A branch for each feature seems to make it more complicated, while we're trying to reduce complexity. Also, if there is a bugfix (i.e. for 1.0), it can be done on a branch made from the tag. Then we can tag that branch (making a 1.1), release it, and merge the bugfix into the trunk. Development of the large feature would continue on the trunk. –  Peter Jul 7 '11 at 6:57

2 Answers 2

up vote 6 down vote accepted

IMHO working directly on the trunk is fine if you can commit in small increments and you have continuous integration in place, so you can ensure (to a reasonable extent) that your commits don't break existing functionality. We do that too in our current project (in fact I haven't worked in any project using task-specific branches by default).

We only create a branch before release, or if a feature takes a long time to implement (i.e. spans multiple iterations / releases). The rough size of a task can almost always be estimated well enough so that we know in advance whether we need a separate branch for it. We also know how much time is left before the next release (we publish releases approx. every 2 months) so it is easy to see whether or not a task fits into the time available before the next release. If in doubt, we postpone it till the release branch is created, then it is OK to start working on it on the trunk. So far we needed to create a task-specific branch only once (in about 3 years). Of course your project may be different.

share|improve this answer
1  
I'm with Peter. We have a branch for each supported release, but otherwise work in trunk. We also use Continuous integration, but be aware this only means it will compile and not that it hasn't broken existing functionality, even with unit tests. –  Ian Jul 6 '11 at 15:55
    
@Ian, of course no test can ensure in real life that the code is 100% bug-free ... having limited resources, we aim for a reasonable level of safety (the definition of which is domain- and project-specific). Note also that CI can run integration etc. tests too, not only unit tests. –  Péter Török Jul 6 '11 at 16:02
    
This works until it fails. If you need to implement a fix before the new feature is ready... Or if a new feature release wasnt as ready for primetime as you thought it becomes much harder to back that change out of the code if you do not use branching. –  Chad Jul 6 '11 at 16:29
    
@Chad, patches to the latest release are done on the corresponding release branch, with no interference from the trunk. And we test new features fairly extensively so we know when they are ready for prime time. Granted, we have relatively few big features in our project. And since it is a server side web app, it is fairly easy even to add a DB flag to selectively turn features on/off. YMMV. –  Péter Török Jul 6 '11 at 16:43
    
LOL ok I mis understood and thought you just had the trunk (with one exception) I have used this method as well its fine for a small group and frequent small releases it didnt work well for us doing large releases on regular (3-6 month) intevals. –  Chad Jul 6 '11 at 18:08

What you are describing with your feature development is parallel development (simultaneous development targeting different product releases) and it does require branches to handle it properly. You could have one branch either for each release or for each feature if you often have to recompose the features that will make a particular release.

The other way to do this, would be to work out of trunk by default but create a branch if you expect your task to extend past the next release. You always tag the release of course.

Which approach you take really depends upon how much management you can do upfront. If the typical release doesn't really have parallel development then I'd take the second approach.

share|improve this answer
    
I agree and OP confirmed this with: 'Sometimes, a feature is almost ready, and some developers will already start coding the next feature...' –  Chris Jul 6 '11 at 16:33
    
Yes, but we never have to recompose. Features are implemented chronologically and, for example, features 1-4 all have to be in the next release (say 1.0). The only time this could be problematic is when development has started on feature 5, which is for the release after that (2.0). Then we must ensure these changes aren't taken along in the tag/release (1.0). Making a branch prior to the release could indeed fix that. –  Peter Jul 7 '11 at 6:54

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.