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."
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 ^^
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 monotone project needs developers to create a free software tool solving the same problem. We really do need good tools that are free.
You know, I don't think that can possibly be an enforcable license provision. That would be like M$ trying to control what sorts of papers people could and couldn't write with Word.
Craig Steffen
http://www.craigsteffen.net
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.
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?
BitKeeper has distributed revision control and history-sensitive merge support. Of the alternatives you mention, Arch is the only one which is comparable.
The GCC project is of comparable complexity to Linux. They use CVS with some success, don't they?
Some, largely because they have a great deal of process set up around beating CVS into submission. It's much more work and dicipline than most teams are willing to go through, though.
or like MS not allowing developers to write a MS Access competitor or other competing software using Visual Studio?
i) your Licensed Product shall not substantially duplicate the capabilities of Microsoft Access or, in the reasonable opinion of Microsoft, compete with same;
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?
*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.
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
That doesn't work though. It's like selling a physics textbook and saying that you can only read it if you agree not to write a another physics textbook using what you learned. It's bullshit.
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.
thus the improvement.
Come now, did he NOT leave transmeta and go to OSDN and now has a lot more TIME for kernel work? Regardless of the tool.. more time = more production.
BK may be better but the tool is only as good as the operator.
I can program myself out of a Hello World Contest!!
What about Darcs? We're using it for the Vexi project and it seems to be VERY good.
That would be an extreme view. Most just realize that there is a significant risk in using proprietary infrastructure. Imagine BK had no bridge to CVS. BK starts charging a lot of money to use BK (monthy fee even). Great, so the kernel hackers check out the code and put it in CVS - no big deal. Next SCO comes along and makes claims about the history of the code. Oh wait, the history only goes back to the switch from bitkeeper.... Oh, but the last BK archive is still around - oh but BK went out of business so it's not accessible....
It's OK to use proprietary tools when working on your bread and butter, but they must not be able to prevent you from having full access to said bread and butter.
Are your business documents stored in MS Word format? What will you do when they switch to a subscription model and charge $$$ per month? Save them all as .rtf or .txt and import into OpenOffice.org? What if support for saving those formats is removed before the price goes up? Remember, in this scenario it's YOUR data that is not under your own control. Certain things just shouldn't be proprietary, and most people never thought about that when they allowed it to happen.
Yes, yes, I know that there's a BK->CVS mirror. Still means that one has to use suboptimal means to submit changesets back upstream.
That said -- frankly, I regret my involvement in this thread; I was, admittedly, shooting my mouth off without cause.