Slashdot Mirror
Bitkeeper News Redux
gosand writes "Newsforge is running Part 1 of a two-part interview with Bitkeeper author Larry McVoy. You may recall that there was quite an uproar in the community over Linus choosing to use a proprietary source management tool. Although there are no hard numbers, the estimates are that Linus has been 10x more productive with BK."
What we did to arrive at that number was to simply measure the amount of change over the two-year period in BitKeeper and contrast that with the two-year period before BitKeeper. It worked out to about 2.5x more change.
I'm no mathematician but I'd say that's a decent way of estimating their productivity increase. But does BitKeeper actually help that much? Anyone who has every used it in a production environment please comment.
Linus is processing around 50 patches a day, 365 days a year.
That's a pretty incredible number. If that's the truth, then I'm very impressed.
Wireless News www.DailyWireless
Although there are no hard numbers, the estimates are that Linus has been 10x more productive with BK.
And I'm 1000x more productive with CVS!
Instead of pulling numbers out of the air, just say the guy likes the tool and performs better with it. Sheesh.
Javascript + Nintendo DSi = DSiCade
...You may recall that there was quite an uproar in the community over Linus choosing to use a proprietary source management tool. Although there are no hard numbers, the estimates are that Linus has been 10x more productive with BK...
No interest whatsoever in being a flamebait here so...
Though no hard numbers exist and this is largely speculative all around, one would have to applaud Linus for using any tool that is making him 10x more productive.
I have a theory that the truth is never told during the nine-to-five hours. -- Hunter S. Thompson
There are other things to think about for terms of productivity. Like, how much time per day is he putting into it? How much faster is his setup to allow him to apply patches? Are the patches more/less/equaly in size to the ones from years ago when Linux was getting off the ground.
Evolution or ID?
"BitKeeper has made me more than twice as productive, and its fundamentally distributed nature allows me to work the way I prefer to work - with many different groups working independently, yet allowing for easy merging between them." -- Linus Torvalds, February 2004
;)?) or what?
Interesting... and BTW, is BK just another SCM(is that the right acronym
If it is, I'm using Subversion, and it's nice ^^
Why there was an uproar over this. Who cares if it's Free or not? It gets the job done better, and in the end that's what counts. The flame wars all over LKML and other places were just wastes of time.
BLING BLING. Meet the architecture that's changing everything.
The lesson to be learned here is very simple...
Open source and propriety software can and should be used hand in hand. The best tool for the job etc. etc. The OSS scene suffers from the idea they are members of some religion and by using anything other then Open Source they are committing a crime against the movement.
Please do not let scientific accuracy interfere with the intended humourous/interesting/insightful value of this comment
BitKeeper is a fine product. Check out the other fine products in the same product line:
*BitCreeper debugging tool
*BitSleeper archiving tool
*BitDeeper anti-anti-enhancement spam tool
*BitPeeper anti-anti-porn tool
-[joke removed for your safety]-
The arch people have been making a lot of noise recently, and I've seen more projects using it. Does arch aim to provide the features that BK has currently? How close are they? Has anyone got any experiences to share?
Sometimes the correct decision is to make a decision and stick with it. I hate it when people go back and forth, and can't really nail down what they want to do. I admire that Linus made the decision, stuck with it despite outside pressure, and has proven to at least be much more productive than he was before. Linux has come a long way both technically and work-flow-wise in the last couple of years. It sounds like BK is doing a good job, even if it isn't FOSS.
Great ideas often receive violent opposition from mediocre minds. - Albert Einstein
"...the estimates are that Linus has been 10x more productive with BK." Does that mean we have a new unit of measurement for benchmarking?
Actually, it's meaningless without looking at other factors. Even the concept of more change is so open ended it tells us nothing. As Linux gains users it will certainly increase in these numbers, there is no strong indication that bitkeeper is a factor at all, or how much of a factor it is.
Although there are no hard numbers, the estimates are that Linus has been 10x more productive with BK.
Following the statement that there are no hard numbers , the ten percent figure seems more like a number pulled out of thin air and selected to not be large enough to be called outrageous but big enough to encourage people to make a change. That's not to say we are not talking about a good tool here (I have no opnion on that issue), but this is much more hype than a valid study.
I'm an American. I love this country and the freedoms that we used to have.
The monotone project needs developers to create a free software tool solving the same problem. We really do need good tools that are free.
With no hard numbers the 10x number is absurd. I misread it as 10%, and even that number seemed hard to justify since all factors were not considered. 10x is an outrageous claim, and would imply that Linus previously spent almost all his time not doing programming.
I'm an American. I love this country and the freedoms that we used to have.
We derive benefit from the pro bono work in other ways as well. When we are testing out a new release we can put it on bkbits.net and we know in seconds if we have broken something important; people use old versions of BK to talk to bkbits.net every few seconds.
Perhaps having the repository where Linux and other projects are hosted being broken to older clients now and then is a bad thing for a community (though the bk people obviously see it as positive for them - free testing). I understand they're providing everything for free, but perhaps Linux might be better off on a community-supported service (still running Bitkeeper) that is concerned a bit more production status?
I'm not intimately familiar with this, so it's just my two cents, feel free to argue.
"The universe seems neither benign nor hostile, merely indifferent." --Carl Sagan
Folks -- the 10x productivity number mentioned in the article was only an anecdotal claim; Larry McVoy claimed 2x. And the latter number is backed up by some pretty fair reasoning. I RTFA and didn't get the impression anyone was pulling numbers out of their ass.
S
That's not to say that BitKeeper is the only way to get that effect, however. GNU Arch is another distributed revision control system, and Free Software to boot.
:)
"BitKeeper makes Linus 10x more productive" might be generalizable to "distributed revision control makes Linus 10x more productive" -- pity we don't have more sample data yet.
Unlike a lot of you, Linus isn't a Linux zealot. He's said on more than one occasion that Linux/OSS is about making the right tool for the job when one doesn't already exist. It has nothing to do with shoving an ideology down everyone's throat.
In this case, Linus decided that Bitkeeper was the best tool for the job, and it is very telling that people are judging him for not complying with an almost religious ideology that he doesn't even subscribe to.
"Ask not what your country can do for you." --John F. Kennedy
There has been a noticable improvement in the 2.5-2.6 cycle compared to 2.3-2.4. Linus and the team has done a super job. Bitkeeper gets a lot of credit for it. I can't help but wonder if similar results would not have been achieved with CVS, Subversion, or arch. Are there any features Bitkeeper has that the free alternatives do not?
The GCC project is of comparable complexity to Linux. They use CVS with some success, don't they?
an ill wind that blows no good
And for the rest of us who enjoy using free software, there's the Subversion (also known as SVN) revision control system.
The article makes some moot points comparing BitKeeper to CVS - since I'm fairly sure anybody who's tried SVN would never want to go back to CVS. I now recoil in disgust whenever I have to access a CVS database - SVN's implementation solves problems in a much cleaner way than CVS and has far fewer rough edges.
IIRC he was not using any SCM at all so yes using one in gneral will help. CVS for me was able to get my team about 10x better (but then again I did most of the work anyways and this was for class).
But anything not using a SCM will be helped by using one.
I remember a discussion about this a while back and a number of people saying that Subversion should be used but isn't yet ready. I'm certainly ignorant of the nuances of version control systems. Does anyone have an update on how Subversion compares to Bitkeeper especially as it might handle kernel development?
"When we are testing out a new release we can put it on bkbits.net and we know in seconds if we have broken something important; people use old versions of BK to talk to bkbits.net every few seconds."
I'm sure they're experts in code management, but their testing procedures could use some work.
In all matters of opinion, our adversaries are insane. -Oscar Wilde
*I may be wrong*, but I presume that is to prevent people from producing pass-through programs that use Access as a component and just duplicate Access functionality. As a Studio developer (Enterprise edition only, IIRC?) you can use Access as a component in your compiled software without the end-user having to buy an Access licence. So this is to prevent someone packaging up the Access engine in such a product as a new piece of database software, not preventing you from writing a new database from scratch using Visual Studio.
Remember that this number is about perception. Linus himself says he's more than twice as productive. The other developers say he's 10x as productive.
But what's their measurement? The number of patches from them he accepts. For years, Linux development was badly hamstrung by the fact that Linus couldn't work fast enough. The patch submission process, was, in essence, emailing him over and over and over, hammering away at the poor guy, trying to get your patch noticed. The developer frustration with this process was EXTREME. The single most common thing I heard about kernel development was "Linus doesn't scale". BK has changed that completely.
It seems entirely possible to me that Linus is now 10x better at processing and merging patches. But that's not all he does.... a 10x improvement in patch management could easily translate to a 2x overall productivity increase. Measurements of code changes show about a 2.5x overall improvement, which is pretty close to Linus' own guess.
In other words, these numbers aren't incompatible... productivity is a hard thing to measure, and there are a lot of angles from which you can look at it.
If the claim of 50 patches a day, 365 days a year are true... that's 18,250 patches a year. The fact that he can do that and get coding done TOO should be an object of reverence and awe.
Since BK was designed with Linus in mind, it probably won't affect other programmers as dramatically as it did him. Not all coders will think like he does, and his distributed coding needs are very specialized. It's not going to be applicable to all environments, but it's pretty obvious that at least in some cases, it is an enormous win and completely worth what they're charging for it.
Larry referenced some stuff I wrote for Open Source magazine recently. Here's the basic information if anyone wants to know what the real rate of change was for the 2.6 kernel development cycle. As for if it is faster than 2.4 we don't have real numbers (bk wasn't being used) but you can take the diffs and compare them for yourselves...
The Linux 2.6.0 kernel was released after 680 days of development. Here are some statistics about the development cycle during that time period:
- 27149 different changes were accepted into the kernel source tree. That averages out to about 1.66 changes per hour over the entire 680 days.
- 916 different developers contributed at least one kernel patch.
- 413 different developers contributed one kernel change.
- 117 different developers contributed two kernel changes.
- 57 different developers contributed three kernel changes.
- 38 different developers contributed four kernel changes.
- 20 different developers contributed five kernel changes.
- The top 10 developers contributed 10933 kernel changes.
- The top 5 developers contributed 6956 kernel changes, averaging out to about 10 kernel changes a day.
- There were 6175 merges in the kernel source tree, averaging out to about 9 merges a day.
- Including merges and code changes, there were just over 2 modifications per hour over the entire 680 days of development.
Idealism is nice and all but it doesn't get shit done.
Unless you've used BK you really have no idea just how much more powerful it is than everything else. And yes, the p2p model that BK seemingly employs is a big part of it, but only a part of it.
BK has beautiful diff and merge tools. It has incredible file history tools. But most importantly, it's best at doing it's job: accurate revision control while staying near completely out of your face. That's why we used it at SOMA, and that's why I really wish we used it at Alias. Of course, all this really just scratches the surface.
Try it. Check in code. Share it with others. Propogate changes between people. Imagine sharing a development branch served off your desktop without doing any setup other than typing "bkd". Imaging 10 people pushing and pulling code between themselves and the server. Now you understand BK. It's not that source is stored or even the toolset alone. It's the fact that umpteen developers can push and pull between themselves and/or the server and accurately propogate changes all around. Combine that with the tools Larry and crew have written, and now you'll understand why it's better.
And to be fair, I work in the field and I've used SourceSafe, CVS/RCS, BitKeeper, Perforce, ClearCase, arch, Subversion, Accurev, and others. BK is easily the best of them... by far!
--ck
He reviews the much of the changes that are going in, and he has designed some of the larger changes, but the bulk of the programming is done by others. This is why comparing the rate of the merging of patches makes sense in the first place, that is mostly what Linus does.
Just from following the kernel development from the outside it is obvious that things have been working much more smoothly after Linus started using bitkeeper than it has in a long time. In the past there has been several periods where the tension has gotten very high mostly because large number of patches has been dropped by Linus without explanation. Lately this seems to have been no problem at all. And this has happened when the rate of the patches going into the kernel has increased significantly.
There may be other reasons for this too, ofcourse. Things I can think of is that the cooperation with the "kernel lieutenants" has been working better. In particular Andrew Morton seems to do a remarkable good job. And, the fact that Linus now is working full time on Linux probably also helps.
Furthermore, other developers are more productive. It's very easy (assuming you can comply with the licensing terms) to set up your own tree and pull from Linus. In fact, the best way to work with BK is to use many trees, one for each (broad) set of changes you're working on. BK will gracefully handle merging them. Not only developer -> Linus, but also Linus -> developer: when Linus's tree is updated, it's easy for a developer to pull those changes down. It's better all around.
The other, very convincing, argument is that all of the previous 'functionality' is there, and then some. Linus still creates releases in the same way--you can just get stuff earlier with BK. The release notes are better, because they're generated from BK, and include the author's name and comments, not just Linus's summary. You can still send diff-style patches via email. Bitmover also added CVS gateways for those who want early changes without using BK. The LKML community was extremely skeptical to say the least, but pretty much everyone except the rabid zealots are convinced.
Larry used to like to joust with the would-be bitkeeper challengers. I'd like to know what he thinks of them today. My guess is that he still thinks arch is limited by its "diff&patch" foundation, but I wonder what he thinks about darcs", which has some novel algorithms for distributed revision control (I admit I don't understand them all, not being a physicist).
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
In other words, this article basically means that using -some- source code management system makes you more productive than plain old backups. One word: duh.
Move along. Nothing to see here.
Check out my sci-fi/humor trilogy at PatriotsBooks.
Many kernel developers send their changes in via
the top few developers. This causes changes to get
credited to the wrong person.
So there are many more than 916 different developers,
and the top 5 developers aren't as active as you
thought they were.
This seems like just another example where the Free/OSS model has failed.
There are many FOSS alternatives to Bitkeeper such as CVS, Subversion, and arch. And none of them come close to the productivity of this one commercial package.
Why is this? Sure, we've got peer review, no deadline/bottom-line pressure, but we still get outdone. Where is Eric Raymond's bazaar now?
Don't get me wrong, I'm a strong believer in OSS, and occasionally contribute, but there are still areas where we are sorely lacking.
When was the last time you saw a decent FOSS fps game? Crystal Space looks promising, but it's just an engine. Look at Tux Racer, another example of FOSS failure. The game was forked when the original developer decided to go closed source, and the GPL'd OpenRacer project was started. Today the closed-source TuxRacer is a rather beautiful full-featured game, and the FOSS version hasn't progressed beyond a novelty.
Then we get to see Blender, a shining example of when FOSS developers adopt a formerly closed-source project and do it right.
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
The GCC project is of comparable complexity to Linux. They use CVS with some success, don't they?
The FreeBSD project also uses CVS for development. Keep in mind that FreeBSD is a kernel AND an userland, which might qualify it to be an even more complex project to manage than Linux.
And on a lesser scale, there is also the example of the Mozilla project which uses CVS with a good share of success.