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

Re:Productivity

[dresgarcia]

"Here's how that announcement came about. I asked someone we were considering hiring why he wanted to come work for us. His response was, "I hang out on the kernel list and it is obvious that Linus is ten times more effective since he switched to BitKeeper." That sounded pretty nice, but I didn't believe it. I knew things were better, but ten times better? That sounded a little too good to be true."

Did you bother to read the article before posting? They say the real number is closer to 2.5x.
Sheesh.

Re:I don't see

[WanderingGhost]

Who cares if it's Free or not?

I usually don't, butif you read the BK license, you will notice that it disallows you to work on competitors (including CVS and subversion) if you are a BK user. I think at least one of the subversion developers (who also contributes to the Linux Kernel) is not allowed to send Kernel patched using BK because of that (he sends them via email).

Re:BitKep'R

[Benabik]

BK uses a more distributed development model instead of having one central server, which allows people to maintain their own version controlled source tree from which Linus (or anyone) can pull patches from. This is more like Arch [gnuarch.org] or SVK [elixus.org] than CVS or Subversion. Although in the end it performs a similar function, the difference is fairly significant.

Re:BitKep'R

[Unknown Lamer]

Subversion is a CVS replacement. It is not and will never be as powerful as Bitkeeper. It does its job as a CVS replacememnt well.

The only Free SCM that can be compared with Bitkeeper is Arch [srparish.net]. Arch should be able to replace Bitkeeper in the future if not already (it's been a while since I used Arch). It is Free Software and part of the GNU Project now too.

Re:I don't see

[zulux]

It gets the job done better, and in the end that's what counts

I've used many peices of software that have gotten "the job done better."

And, I've been burned too many times to count when the company that makes the software changes focus or goes out of business.

Free Software, for me, is great insulation from forced migrations, "upgrades" and unsupported software.

Re:I don't see

[pqdave]

IIRC, the "not for BK competitor" is for the free version, the paid version has no such restrictions.

Re:BitKep'R

[trance9]

Arch is not the only one, monotone [venge.net] is another, cleaner tool.

Re:arch?

[IamTheRealMike]

I haven't used BitKeeper (I can't as I have done a couple of trivial bugfixes in arch, duh), but arch works pretty well for me. It could be a bit faster, but I like its transparent design and responsive and friendly community.

The fact that it's actually used outside of one project/domain (unlike BitKeeper) also helps as there's a wider pool of experience to tap into.

Having said that, while it's maturing fast it still has an evil UI (no Tom wrappers are NOT an acceptable solution for that), and lacks some important features like being able to turn a changeset into a flat text file and then email it in one command. If you're willing to do some scripting arch is the most powerful SCM I've ever seen, but it could always be better.

Finally it's a bit misleading to say that it was BitKeeper that made Linus 10x more productive. Before BK they didn't use any source control at all, and all patches were sent either in private email or onto lkml. It's not surprising that using source control improved things!

For comparison, Alexandre Julliard who maintains Wine processes approximately 100 checkins a week, so that's about 14 a day. We use CVS with a single committer. Given that Alexandre actually codes a lot as well, I think it's pretty clear that Linus' "productivity boost" more to do with being able to work full time and having a decent project structure (we all send patches to a dedicated mailing list for instance and we don't have a ton of "lietenant" trees) than anything magical about BitKeeper.

Re:Pretty impressive productivity increase

[Short Circuit]

He doesn't make them, he reviews them. I'm no expert, but I'd guess he gives them a quick look over for obvious breakage and other no-nos.

Re:BitKep'R

[casret]

Yeah, it's the correct acronym, (Software Configuration Management (I don't get it either)).

I've used a bunch of them over the years, it's a bit of a hobby for me. I won't try to do a comparison of them all, there's one

here. But I'll give some general impressions. BK is definetely the best of the bunch so far. The distributed nature, the solid tools around it, the don't lose any piece of change data philosophy.

I've been on an Arch kick though, it follows the same principles, distributed repositories and all that, but there aren't as many tools around for it quite yet, but I think it's building a community around it. There are some idiosynchrocies that bug me though.

Still haven't gotten around to playing with Subversion, it just didn't seem ambitious enough for me to bother with.

Perforce and CVS are the other ones I have the most experience with. They are pretty typical for a client-server type model of SCM, with Perforce being well supported on the commercial end. That external database gets large and slow though if your tree gets too big.

Re:I don't see

[Anonymous Coward]

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.

Hopefully unenforcable, but remember that Microsoft has *this* clause in their Visual Studio EULA:

1.2 Documentation. This EULA grants you, as an individual, a personal, nonexclusive license to make and use an unlimited number of copies of any documentation, provided that such copies shall be used only for personal purposes and are not to be republished or distributed (either in hard copy or electronic form) beyond the user's premises and with the following exception:

you may use documentation identified in the MSDN Library portion of the SOFTWARE PRODUCT as the file format specification for Microsoft Word, Microsoft Excel, Microsoft Access, and/or Microsoft PowerPoint ("File Format Documentation") solely in connection with your development of software product(s) that operate in conjunction with Windows or Windows NT that are not general purpose word processing, spreadsheet, or database management software products or an integrated work or product suite whose components include one or more general purpose word processing, spreadsheet, or database management software products. Note: A product that includes limited word processing, spreadsheet, or database components along with other components that provide significant and primary value, such as an accounting product with limited spreadsheet capability, is not considered to be a "general purpose" product.

So apparently, they *do* feel that they can dictate what you produce with your software -- at least by preventing you from looking at their documentation.

Re:Productivity

[gosand]

Then why didn't the article poster say that instead? Sheesh. ;-)

Ahem. I can field that one... :-)

OK, I probably should have used the word "perception" instead of "estimation", because the estimates were about 2.5x.

Here is what it did say in the article:

Here's how that announcement came about. I asked someone we were considering hiring why he wanted to come work for us. His response was, "I hang out on the kernel list and it is obvious that Linus is ten times more effective since he switched to BitKeeper." That sounded pretty nice, but I didn't believe it. I knew things were better, but ten times better? That sounded a little too good to be true. I know some of the senior kernel people personally so I started asking around. I spoke with Dave Miller, Jeff Garzik, Greg Kroah-Hartman, Andrew Morton, and Linus about this. Dave was the first person I spoke with and he said that he thought that 10x wasn't at all unlikely, and it was certainly 8x. Interesting. So I talked to Jeff and his comment was, "Oh, man, it's so much better, it has to be 10x." Greg had a fairly similar reaction.

Here's the rate of change for 2.6

[kroah]

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.

Re:Lesson to be learned

[bwcbwc]

Will you stop it? This thread [slashdot.org] addresses your claim about the license. All you've demonstrated is that you have an axe to grind against your competition.

Re:I don't see

[Richard_at_work]

Ignore my previous comment on this, it is indeed if you have anything to do with a replacement, other than distribute it for free, or use it. The exact clause is thus:

(d) Notwithstanding any other terms in this License, this License is not available to You if You and/or your employer develop, produce, sell, and/or resell a product which contains substantially similar capabil- ities of the BitKeeper Software, or, in the reason- able opinion of BitMover, competes with the BitKeeper Software.

Also on my travels, I also notice that BK does not have this license available for reading anywhere other than within the BK install itself, you need to install BK and then run a command to view the license. Nasty.

Re:Subversion Anyone?

[Eric Smith]

Subversion works quite well, but it uses the central repository model, so it doesn't do the same things BitKeeper does. That said, Subversion is an excellent replacement for CVS. It is almost a drop in replacement, and has file rename/move versioning and atomic commits. It doesn't yet automate repeated merges, but the use of properties makes it easier to track the necessary information. And tagging and branching are almost instantaneous, since they only have to add a small amount of metadata rather that touching every file in the repository.

For a project as large/distributed as Linux, BitKeeper may well be the right thing. For a smaller project where a single central repository is acceptable, Subversion is great. I've converted all my projects from CVS to Subversion, and am pushing my employer to switch as well.

Re:BitKep'R

[William Tanksley]

I suspect others will comment on this too, but there are other close equivalents in the free software world.

Arch is groundbreaking, but it was designed in a rather ad-hoc way, and it _really_ shows. You have to know a lot about the implementation details in order to get stuff done in it.

Darcs is much, much easier to use, and is supported on more platforms (including win32). The shortcomings include slow execution time (due to a complex merging algorithm that's part of the reason it's much easier to use) and an unusual implementation language (I like Haskell, but I recognise that many people don't know it).

OpenCM and Monotone are in much earlier stages of development, and I haven't tried to use either in a production environment.

Bitkeeper still has one big advantage: it's got killer graphical utilities and it's really complete. Both arch and darcs are still growing into their full statures.

But I strongly recommend darcs. I don't see any reason to use any other SCM tool, honestly -- darcs _just works_ and is free. Copy the executables into your path, type 'darcs inittree', and start working; it's just that easy. No worries about file identities, no worries about archive locations; it's all taken care of thanks to a well-thought-out model.

-Billy

Re:sadly, your numbers are bogus

[kroah]

Not true, a number of the main kernel developers use bitkeeper to show who the original developer of the patch was. I know I do, as does Dave, Jeff, and a few others.

Some notible exceptions are Andrew Morton and Rusty's kernel patch monkey. So for people who sent in patches through them, yes you are correct. But the original patch author can easily be determined by looking at the changelogs for those submitted patches. It also would not be that hard for someone to go through and properly fish out the "real" numbers if they so wanted.

But the rate of change is the same, either way.

Re:And for the rest of us..

[tsmoke]

Actually, NO ARCH DOES NOT REQUIRE A CENTRAL ARCHIVE AT ALL.

that's displays a rather fundamental misunderstanding of how arch works, and fairly amusing too. usually, people complain that arch lacks a central server, and that's why it should be avoided.

Re:Pretty impressive productivity increase-Methods

[Anonymous Coward]

Andrew thought that anything would have been an improvement over what Linus was doing before and he agreed that BitKeeper was a lot better than CVS. But his take was that just a move to CVS would have been an improvement. Linus disagreed. Linus was adamant that if he had moved to CVS it would have slowed him down. So in Linus's mind, whatever improvement had happened was due to BitKeeper.

Duh yourself.