Linus On Branching Practices 90
rocket22 writes "Not long ago Linus Torvalds made some comments about issues the kernel maintainers were facing while applying the 'feature branch' pattern. They are using Git (which is very strong with branching and merging) but still need to take care of the branching basics to avoid ending up with unstable branches due to unstable starting points. While most likely your team doesn't face the same issues that kernel development does, and even if you're using a different DVCS like Mercurial, it's worth taking a look at the description of the problem and the clear solution to be followed in order to avoid repeating the same mistakes. The same basics can be applied to every version control system with good merge tracking, so let's avoid religious wars and focus on the technical details."
Re:ClearCase solved these problems years ago (Score:2, Interesting)
Never underestimate the stupidity of some people. I've seen some VOBS get royally hosed and take a day or two to go through the version-trees of individual elements to untangle their merge history. This was all due to two things: 1) OzPeter's Point [slashdot.org] 2) Lazy CM that didn't want to provide simple scripts and lock down a standard method for view/config-spec management.
Re:ClearCase solved these problems years ago (Score:2, Interesting)
ClearCase identified and solved all these problems in the commercial world long before Free software. The problem is that the sort of people who do kernel work don't work for the sort of companies that can afford the ClearCase licensing fees - or at least *mostly* don't.
Well, I'll go with that if you expand the definition to include those who's companies went with ClearCase and who learned first hand how much of a royal PITA it is.
It remains that for many smaller organizations (or teams), something boring but 100% predictable and almost maintenance free like SVN gets the job done just fine. But its not sexy/expensive...
Re:branch/merge is sux (Score:2, Interesting)
Do you really want to do all the validation testing every time you put back to the trunk? Including Installation testing? There are only so many scenarios you can catch with test-first development. The rest are usually discovered by the testers. That's why they still have jobs and why you can actually accomplish anything in a CI environment. There will always be the heroic tales of development teams that are on version 11000 on the trunk and have never busted a customer. Maybe you are him/her? >.>
For the rest of us simpletons, we prefer a validated release to start baselines from.
If you employ a fully featured VCS like ClearCase (or others) you can even run multiple simultaneous baselines releasing feature content while hardening your previous releases...and then merge between them. 0.0 Yes, good SCM teams let you do this and protects you from the worst of your merge nightmares.
Re:This all sounds complicated (Score:5, Interesting)
There are two conflicting goals: to avoid breaking the main branch (trunk) and to get changes out to the other developers soon. A broken main branch wastes the time of other developers on the project. But integrating changes late has its own inefficiencies: Problems in the modifications will only be raised after the work is done. It is more likely for one set of modifications to conflict with another set if both are being developed in parallel for a longer time. Other developers might have to wait for a full set of changes to arrive while they only need a subset, or they might start merging the subset from each other's development branches, creating a confusing mix of versions.
Committing directly into trunk can be acceptable and even desirable depending on the project. It depends on how likely commits are to break the code: How many developers are there? How many mistakes do they make? (a combination of experience and carefulness) Is there decent test coverage before committing? How fragile is the code base; are there many unexpected side effects? And it depends on how much damage a broken main branch does: How long does it typically take to find and fix a problem? How modular is the code base: will a bug in one part be a nuisance to developers working on another part? And it also depends on how much there is to gain from early merging: Is the project in the start-up phase where it is likely that other developers are waiting for new core functionality, or is the code base mature and are most changes done on the edges of the program? Are all design decisions made before code is written or are developers doing design and implementation work at the same time?
Re:This all sounds complicated (Score:4, Interesting)
I go in the reverse.
Trunk is dev, branches are stable. We haven't had much trouble with this set up at all.
it's simply ignorance! (Score:2, Interesting)
The kernel devs don't do development on master! However, git's fast-forward-merge will, by default, push development/intermediate commits onto master. Those intermediate commits are extremely useful for code-inspection/code-review and bisect-based debugging. They're are not meant for starting a new dev branch and that why they're not tagged! There's nothing new or interesting in that article other than a bunch stupid comments at the bottom. The whole thing smells like a disguised advertising for PlasticSCM
The original email complained about failed bisect (Score:3, Interesting)
git allows you to bisect from known-good and known-bad kernels to try and find the source of the problem. The original complaint was that some of the intermediate changes don't build.
The problem here is not necessarily branching/merging, but that maintainers and developers do something along the line of "commit bad change, notice problem, commit fix" in their own private branch. Then, rather than clean up their private branch that whole history gets merged into the main kernel tree.
This has the advantage of showing more details of development, but has the downside that a bisect that hits the "bad change" commit won't build and will require some manual action to select a "nearby" commit that will build.
As I view it, it's less about rebase/merge and more about developers/maintainers being more diligent about keeping their trees clean before merging back to the mainline.
Re:This all sounds complicated (Score:3, Interesting)
We did this where I worked previously too. It was also the MO for the artists building the artwork for the game.
Your trunk is the "Main line", a boiling pot of all the changes and can change on a minute by minute bases right near crunch time; This is good because you fail early if your change is not compatible with other changes instead of at the end of the day or whatever. This is very important for artwork.
The last known good build is tagged/labelled (or branch if you prefer) and was generated by an auto build process that ran tests or the lead/QA department.
Also a admin user (project manager, lead developer etc) could lock the whole project with exceptions for themselves or other specified users (automated build machine user etc). Do a build and test cycle and then mark it as known good release.
The source control system for the artists also allowed changes to be kept separate from the "Main Line" but kept in source control; this is like a branch if you will, but with the difference that you could allow other users or custom defined groups access to your WIP changes. This in effect is like been able to get the latest of the trunk and changes from other users branches at once.
Very useful when a group of artists, 3D modeller, texturer, animator are working on a new area as they can refine it without checking in none working bits to the main line everyone else is working on.