Slashdot Mirror
Linus On Branching Practices
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."
[...] so let's avoid religious wars and focus on the technical details.
Challenge Accepted!
so let's avoid religious wars and focus on the technical details
Hahahaha... Good one!
Developers: We can use your help.
Which I imagine makes sense, as the kernel is very complicated from a dev standpoint.
For most projects I’ve been involved with, the path to success is keeping the trunk in a stable state, and using _that_ as the baseline. Dev code should never be in the trunk imo... the trunk should always be in a ready to release (or proceed to formal testing, or whatever) state. Everyone branches from the trunk.. everyone can update their branch to the latest trunk.. and everyone merges back down into the trunk when it’s good and ready.
Resisting the temptation to make “quick fixes” in the trunk is also important. Additionally, dev platforms should be setup so the system can be run from any branch as easily as the trunk (making it a pain to test out the system from a branch is a great way to ensure unstable code ends up in your trunk).
Obviously in the case of the kernel.. they probably have branches off branches off branches, but I think for most reasonably sized projects, that shouldn’t be necessary.
Or you do what we do: keep trunk pristine - no development should EVER occur in your trunk and it should always be possible to push a stable release from it.
Seems reasonable to me... Don't know why this wouldn't solve the problem, or any other reason why it's not desirable.
weinersmith
Thats what it amounts to. Developers are happily branching and branching off branches with no concern of whether what they branched off was stable in the first place.
I am Slashdot. Are you Slashdot as well?
Even the best merge tools can't guarantee the logic of the merged code is correct no matter how stable/good your branch point is.
OP needs to go back and correct his post so that it reads in the form of a question, please. I don't understand a bit of it.
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 2) Lazy CM that didn't want to provide simple scripts and lock down a standard method for view/config-spec management.
The whole story seems to be summed up by: "Don't just branch from some random point. Wait until your code is stable and branch from that." and "Create these stable points from which you can branch as often as is practical". I'm sorry but I've never been tempted to branch from an unstable point, and I'd be horrified if anyone on my time tried to do so.
As for only adding features to a stable release I find that depends on the size, complexity and maturity of the project. Early on nothing is feature complete and everyone tends to work on an unstable head/trunk/master/whatever-your-scm-calls-it. Once development has settled down and there's been a release, it's much more controlled and people do tend to add their code from a stable point.
I'm sorry I just don't see any life changing revelations here.
These posts express my own personal views, not those of my employer
Here is the actual article that the submitter should have linked to. It's Linus's post. Instead, the submitter linked to his or her advert site, which is a blog that has ads which hawk their own, non-git source control system, all of which you get to read before you are given the link to Linus's actual post.
Some devs know where STABLE is located, some devs know what direction their new code is going, and a successful merge is where a dev violates the Heisenberg Uncertainty Principle and accomplish both at the same time.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
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...
You're special forces then? That's great! I just love your olympics!
Branching and merging is a huge waste of time. I'm not sure why continuous integration is considered just a delaying of the problem. With a CI/streaming model merging happens continuously, not all at one time while trying to hit a moving target. And if CI is not allowed to break, no one has any problems downstream.
this is the second "story" that's really a blog/ad for PlasticSCM. coincidence or kickback?
+a million, spot on.
One of the guys I worked with at my first job working with ClearCase put it thus: "ClearCase is great, it's powerful and flexible. And it gives you plenty of rope to hang yourself with."
From TFA:
"Vaselines are key"
I totally agree.
I don't know why this blog entry quoting linus's entry on the mailing list was considered worthy of an article. What linus said is (or at least should) be obvious to anyone who has a bit of experience participating in any software project which has adopted a revision control system. In fact, surely everyone who ever used a revision control system already stumbled on the dreaded "shooting moving targets" problem on their first contributions to the project and surely they already managed to learn from their mistakes. You only need to reverse a single commit to learn right there and then not to branch from unclean sources. So why exactly is this news?
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
Bogus
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.
SVN is neither.
Slashdot - The great and glorious cluster fuck of Internet wisdom.
SVN is neither.
Ooh, tres trendy. In reality, SVN has powered a staggeringly large number of software projects, as did CVS before it. In the same way that 'ant' (or heck, even 'make') remains remarkably effective for many projects. When you look at 10-500 dev years in a project, your source code control and build maintenance costs can often be in the 10-20 hour range (over the project lifetime). Try that with ClearCase and its brethren. And yes, I've worked on several projects in the 3-10 million LOC range that did just fine with 'make'. Decent templates make almost anything just work - if you have a dedicated 'build expert' or 'sccs maintainer', or those hours/dollars actually show up as something other than noise, then you're doing it wrong.
The reality is that most software projects aren't dramatically unique. They really aren't. Reinventing the wheel is almost always silly, using the 'old' boring solution almost always works and lets you concentrate on the actual innovative software you're designing, rather than having a great innovative code control / translation layer / build system and software that never quite gets shipped.
You're special forces then? That's great! I just love your olympics!