
Linus on branching - fogus
http://codicesoftware.blogspot.com/2010/11/linus-on-branching.html
======
lt
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.

~~~
jedbrown
_they are merged into the trunk_

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

~~~
Goosey
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.

------
lysium
The rest of [http://codicesoftware.blogspot.com/2010/11/linus-on-
branchin...](http://codicesoftware.blogspot.com/2010/11/linus-on-
branching.html) 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'?

~~~
warp
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.

------
adambyrtek
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.

------
pronoiac
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.

------
siculars
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...](http://answers.yahoo.com/question/index?qid=20091109190826AAT40Tx)

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

