Linus on branching | Hacker News Reader

Linus on branching

codicesoftware.blogspot.com

48 pointsfogus12 comments

I think the main issue there is that the trunk is not stable, not that people forked off unstable points.

We only land tested, verified code in the trunk. Each trunk revision is pretty much a separate release. Features are developed in feature branches and multiple features are merged into an acceptance branch for testing. Once accepted, they are merged into the trunk and put in production.

This is using SVN though. I wonder how it compares to a git workflow.

they are merged into the trunk

Do you mean to say that this process never introduces bugs? With subversion's merge model?

I can't speak for the grandparent, but we use a similar system here and also on SVN.

We have a 'core' team and a number of 'project' teams. Every team works in it's own branch, which is branched off of the trunk. The trunk is kept in a stable state.

No one really uses 'feature branches', which I find to be a shame (but hey, it is SVN so feature branches are not convenient). Rather the core team creates a new branch each sprint (scrum here - 3 week sprints) and at the end of each sprint merges it back into trunk, after it has been verified as stable by QA.

Project teams can either branch from trunk and stay off in la-la land until the end of time, or they can try to keep up to date. The way they keep up to date is by merging back into trunk and then starting a new branch. This process is hand-held by the core team and goes through the same QA process to verify it is stable.

How does this work out? Well merging is a major event. Aside from the stability verification work that goes into it a core team member (usually the lead) will generally spend about a day on a merge/branch cycle.

So it feels slow and big, but we do maintain a very stable trunk.

SVN merge issues are a pain, but so long as we never do double-merges (that is, merging a branch into trunk, continuing work on the branch, then merging it a 2nd time into trunk) we seem to avoid the most common gotcha.

This system would be improved if a DVCS was used instead. The issues to adoption of that are both user and technical. We have a wide range of users of widely varying technical skill levels so the ecosystem of SVN clients is going to be difficult to usurp. We also store a LOT of very large binary data in the repository and would find it very inconvenient to separate it out (code version and asset version matching is essential), and in my tests of using git-svn (for example) it simply choked. Like an exception thrown from the bowls of the client type of choke.

It works similarly if you're using the gitflow extension:

https://github.com/nvie/gitflow

http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flo...

Or doing that manually. Git is pretty flexible.

I detect a bit of arrogance on Linus' part here. The conclusions follow directly from the notion that whatever Linus does is right and others should accommodate to that.

In my experience and observation the correct solution to this problem is as you've said, keep the trunk branch stable to as high a standard as you can. That way the cost of stability is pushed to the people making unstable changes, rather than onto every developer.

The rest of http://codicesoftware.blogspot.com/2010/11/linus-on-branchin... is also interesting:

"It's actually made worse by rebasing. A lot of people end up rebasing on top of such a random kernel (again, just because it's the 'most recent'). It's very annoying."

"Not to mention that rebasing easily results in bugs of its own, when you do hit merge conflicts or double-apply something that already got applied (and wasn't seen as a duplicate and merged away automatically, because the code had been further modified since). We had that in the DVB pull request just yesterday."

For me, this sounds like a problem with either the tool or the development process. Any thoughts on how to do it 'properly'?

Yes. Never rebase unless you are absolutely certain that branch has never been published to anyone.

Whenever you want to rebase your branch on top of some other branch, just merge into your branch instead.

"Do not rebase commits that you have pushed to a public repository."

ref: http://progit.org/book/ch3-6.html

This depends very much on a project. Ideally you should have a good test suite assuring that a given revision is correct before merging it into the mainline. If this is the case then every commit on the mainline should be considered an acceptable branching point.

The advice in the article certainly makes sense for the kernel, but could be an overkill for well-tested small and medium projects. Keep in mind that the kernel is a special case both because of its size and the fact that such a low-level and hardware-dependent code cannot be comprehensively unit tested.

My sense is that the latest point release of the kernel is a better jumping-on point for development, rather than from -current, which is volatile & changing multiple times daily.

Perhaps when they start the branch, it's expected to be a small fix, & that it won't last very long. Making it work & making sure it won't break anything will be quick. So you'd try to keep your merge costs down by starting from the most recent version.

It's optimizing based on faulty information. Building on a dev kernel might be really hard to troubleshoot, & merging is easier than that.

Getting involved with protracted git usage discussions is like trying to follow Doc Brown explain the vagaries of the time continuum[1].

[1]http://answers.yahoo.com/question/index?qid=20091109190826AA...

Wow, i had no idea plastic scm existed, pretty cool. No capistrano module yet?

Reply on news.ycombinator.com