Comments on: Version Control: developing on branches rather than master/trunk

By: alex

alex — Mon, 21 Feb 2011 17:32:29 +0000

It’s really about breakage, or rather your commit breaking somebody else’s code. I like to commit often which is why I use Git (but any DVCS will do). In effect, I’m always developing on a branch. Personally, I like trunk/master to always pass all it’s tests, and this isn’t likely if non-feature-complete commits are going back to trunk/master.

However, there’s nothing intrinsically wrong with the approach you suggest.

By: allard

allard — Mon, 21 Feb 2011 10:53:19 +0000

Hi,
Why would you need a trunk/tags at all? Can’t we just say we start developing at version/v1.0. All bugs and issues can then be connected to the version where you want it fixed. Any large development can still be done in branches, but the goal is to deliver v1.0 anyway, so that’s where you commit. Then someday you install a customer version (which is of course v1.0), that’s when you create v1.1 (a tag of v1.0) and continue developing there. If you discover some bug or even a new feature that simply has to be included on the already installed version v1.0, then this can be done easily, and can be merged to v1.1 as well. This can be continued on and on. The only thing is that all developers need to know in which version to do the development.
Is there anything against this approach?

By: alex

alex — Sat, 25 Sep 2010 18:40:43 +0000

You raise some interesting points which I think are a feature of any non-locking version control system. You’re right, it does have to be handled carefully. I think that the main thing is to ensure that the main trunk is controlled by one or two people who can test the merges before the are updated to the trunk. Obviously, this relies on a good test suite.

The SVN tag==branch is probably a design flaw. Tags ought to be immutable, and so it shouldn’t really be able to checkout a tag, work on it and then update to that tag.

I’m still pondering whether ‘develop’ in branches is the right idea. On subversion, branches feel to heavyweight, whereas it seems really easy in git to develop in a branch and then quickly merge back in.

So on reflection, in subversion, we develop on trunk, but ensure that it always ‘works’ by using a post-commit hook, but in git I tend to develop on a branch.

By: Corfiot

Corfiot — Tue, 31 Aug 2010 14:45:41 +0000

I mostly agree with you, however the solution you are moving to needs a bit more refinement. Between steps 2-3 and 5-6, i.e. when merging, how do you know that just after you merged and while you’re testing that there has been no change in the trunk? If you don’t come up with a way to synchronize merges you’ll end up chasing your tail trying to keep track of which fix is in what branch. So, I guess you may need to implement some kind of freeze-before-merge system.

If everyone develops in branches exclusively, this is easier as trunk will not be modified on a daily basis by any team… And working on tickets is a must so you keep track of the feature and its patch-set.

As for releases, I’d definitely tag the release on the trunk. Now if you are on release 2.5 and you get a bug on 2.1 that was fixed on 2.4, you need to backport the fix for customers using 2.1-2.3. Then you simply work on the “tag”. At least in SVN the tag IS a branch. So you check it out and fix it. Downside: you have to do this for 2.2 as well (all intermediate tags).