Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Software Linux

Bitkeeper News Redux 278

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."
This discussion has been archived. No new comments can be posted.

Bitkeeper News Redux

Comments Filter:
  • by mindless4210 ( 768563 ) * on Tuesday May 11, 2004 @02:43PM (#9119192) Homepage Journal
    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.
    • by millahtime ( 710421 ) on Tuesday May 11, 2004 @02:47PM (#9119234) Homepage Journal
      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.
    • by frovingslosh ( 582462 ) on Tuesday May 11, 2004 @02:54PM (#9119316)
      I'm no mathematician but I'd say that's a decent way of estimating their productivity increase.

      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.

      • 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.
        • 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 t
      • by Izago909 ( 637084 ) <tauisgod@[ ]il.com ['gma' in gap]> on Tuesday May 11, 2004 @03:27PM (#9119623)
        I guess it all boils down to what Linus thinks. If he feel's it's better, and helpes increase his production, then that's all that matters. Something as complex as this will prove very difficult to make hard numbers with because of the large number of uncontrolable variables.
    • Linus is processing around 50 patches a day, 365 days a year.

      Bullshit. The guy never gets out to take a walk, or go for a drive in that yeallow sports car of his or, heaven forbid, take his kids to the fucking zoo for the day.

      Yeah, he just sits there, 365, 24x7, turning out patches.

      Please.

    • Depends. Did the move to BK come before or after IBM jumped in and started donating huge amounts of code to the kernel, companies started pumping out device drivers, and Linux became a well-known name in IT circles?

      I'd be willing to bet that KDE and Gnome have accelerated a lot since Linux moved to BK, but I don't think that anyone would assert that BitKeeper should get the credit.

      In short, that move happened at a fixed point in time when a whole lot of other interesting things were starting to happen. Was BK causative or correlative? I'd put money on the latter.

    • by amightywind ( 691887 ) on Tuesday May 11, 2004 @03:09PM (#9119468) Journal

      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?

      • by cduffy ( 652 ) <charles+slashdot@dyfis.net> on Tuesday May 11, 2004 @03:17PM (#9119541)
        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.
        • Which one would be best to archive all my Slashdot sigs. I can't just look at my old posts and copy them back cause they all change!!

        • SVK [elixus.org] supposedly has distributed revision control and different flavours of merging. SVK uses Subversion as a versioned filesystem.
        • What about Darcs [abridgegame.org]? We're using it for the Vexi project and it seems to be VERY good.
      • by Cochonou ( 576531 ) on Tuesday May 11, 2004 @06:23PM (#9121427) Homepage
        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.
    • by Spoing ( 152917 ) on Tuesday May 11, 2004 @03:10PM (#9119472) Homepage
      1. Linus is processing around 50 patches a day, 365 days a year.

      Active cooling, a dedicated fan, a big heat sink, and he should get up to 60-75 patches a day. No need to wait a year or two for Moore's law -- these changes can happen today!

  • Productivity (Score:5, Insightful)

    by AKAImBatman ( 238306 ) <akaimbatman@gmaYEATSil.com minus poet> on Tuesday May 11, 2004 @02:45PM (#9119205) Homepage Journal
    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.

    • Re:Productivity (Score:5, Informative)

      by dresgarcia ( 251585 ) on Tuesday May 11, 2004 @02:52PM (#9119288)
      "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.
      • Did you bother to read the article before posting? They say the real number is closer to 2.5x.
        Sheesh.


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

        • Accuracy? From an article submitter?

          lol - what next, you want the editors to make sure there isn't a dupe already out there?

          -- Ravensfire
        • Re:Productivity (Score:4, Informative)

          by gosand ( 234100 ) on Tuesday May 11, 2004 @03:36PM (#9119711)
          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.
          • OK, I probably should have used the word "perception" instead of "estimation", because the estimates were about 2.5x.

            You look like a good kid. I'll let you off with a warning this time. Just don't do it again! ;-)
      • I'm 3.14159x more productive but I'm stuck in a loop.
    • by grub ( 11606 ) <slashdot@grub.net> on Tuesday May 11, 2004 @02:53PM (#9119304) Homepage Journal

      I'm 10x more productive when I don't read /. at work.
      • I'm 10x more productive when I don't read /. at work.

        I don't think I could say that for myself because 10 x 0 is still zero.

        I would have that simply say that I am productive when I don't read /. at work. When I read /. at work, my productivity isn't mostly dead, its all dead.

  • ...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.
  • BitKep'R (Score:4, Interesting)

    by Leffe ( 686621 ) on Tuesday May 11, 2004 @02:47PM (#9119238)
    "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

    Interesting... and BTW, is BK just another SCM(is that the right acronym ;)?) or what?

    If it is, I'm using Subversion, and it's nice ^^
    • Re:BitKep'R (Score:5, Informative)

      by Benabik ( 31932 ) on Tuesday May 11, 2004 @02:54PM (#9119313) Homepage
      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 (Score:4, Informative)

      by Unknown Lamer ( 78415 ) <clinton@nOSPAm.unknownlamer.org> on Tuesday May 11, 2004 @02:58PM (#9119362) Homepage Journal

      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:BitKep'R (Score:4, Informative)

        by trance9 ( 10504 ) on Tuesday May 11, 2004 @03:10PM (#9119481) Homepage Journal

        Arch is not the only one, monotone [venge.net] is another, cleaner tool.
      • Re:BitKep'R (Score:3, Informative)

        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) a
    • Re:BitKep'R (Score:4, Informative)

      by casret ( 64258 ) on Tuesday May 11, 2004 @03:23PM (#9119586)
      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.
      • (Software Configuration Management (I don't get it either)).

        You don't get it because it's wrong :P. It's source code management, hence it managing source code.

  • I don't see (Score:4, Insightful)

    by Power Everywhere ( 778645 ) on Tuesday May 11, 2004 @02:48PM (#9119256) Homepage
    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.
    • Re:I don't see (Score:4, Informative)

      by WanderingGhost ( 535445 ) on Tuesday May 11, 2004 @02:54PM (#9119309)
      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:I don't see (Score:3, Interesting)

        by gevmage ( 213603 )
        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.
        • Re:I don't see (Score:4, Interesting)

          by happyfrogcow ( 708359 ) on Tuesday May 11, 2004 @03:18PM (#9119546)
          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;

          • MS Scaremongering? (Score:3, Interesting)

            by blorg ( 726186 )
            *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
          • Re:I don't see (Score:5, Insightful)

            by rabtech ( 223758 ) on Tuesday May 11, 2004 @03:42PM (#9119771) Homepage
            The key difference is that if you duplicate MS Access with VS, you are using ADO which contains the Microsoft JET engine (among other drivers); in effect, you are using the access engine to write a product that competes with access.

            In the BK instance, you are NOT using BK as the basis to develop a competing source control product.

            The BK license (at least regarding that provision) is not enforceable and has all the weight of feather to back it up.
        • You might think that requiring people to distribute any modifications they make to your product to be an unenforceable license.

          The logic goes, you wouldn't have a license at all if I didn't grant it to you somehow, so you can't complain about the terms. All you can do is reject the license and not use the product. I can require you to wear a heatsink on your forehead if I want to.
      • Re:I don't see (Score:3, Informative)

        by pqdave ( 470411 )
        IIRC, the "not for BK competitor" is for the free version, the paid version has no such restrictions.
        • IIRC, the "not for BK competitor" is for the free version, the paid version has no such restrictions.

          Which is the one used for Kernel development, if I'm not mistaken...
          • IIRC, the "not for BK competitor" is for the free version, the paid version has no such restrictions.

            Which is the one used for Kernel development, if I'm not mistaken...

            It's irrelevant what license other kernel developers are using. If you want to contribute to a BK competitor and the kernel you need to either pay for BK, not use BK, or ask Larry nicely for an exception (which he has said he's willing to consider in individual cases). I can't see anything wrong with that policy.

      • 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.
        The BK restriction only applies if you are using the free license. You can do whatever you like if you pay for it. Basically: "we'll give you BK for free, but you're not to use it to undermine our business". Seems fair to me.
    • Re:I don't see (Score:5, Informative)

      by zulux ( 112259 ) on Tuesday May 11, 2004 @03:01PM (#9119391) Homepage Journal
      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.

  • by WordODD ( 706788 ) on Tuesday May 11, 2004 @02:49PM (#9119268)
    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.
      1. 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.

      While I agree this is the case, OSS is often seen as 'freeware' by most people. This in itself is dammaging far beyond the rants of a few OSS advocates.

      (For the record: I'm using Linux 2.6.5 with NVidia's video drivers, have paid for Transgaming's WineX, Crossover Plugin and Office, VMWare, numerous native and ported Linux programs,. At t

    • Not if you fall into the RMS crowd.
      Which believes proprietary software is immoral pure and simple.

      It seems OSS falls into two groups: pragmatic and idealogical.

      And as time moves along the differences between the two grow larger.

    • by cduffy ( 652 ) <charles+slashdot@dyfis.net> on Tuesday May 11, 2004 @03:24PM (#9119600)
      No, the BitKeeper license is evil. Go read it sometime -- it prevents folks from working on competing systems. This means that folks working on Free revision control (like me!) are substantially hampered if we want to also do some work on the Linux kernel.

      Larry has also been known to change license terms specifically to force a particular user to upgrade to a more expensive license -- I was an employee at a Linux startup (MontaVista Software) when it happened to us. He's been known to spread FUD about Arch in public, and is otherwise not a very nice person to have as a competitor *or* a supplier.

      Particularly given that Free alternatives [gnuarch.org] to BitKeeper with history-sensitive merging and distributed repository support (the two features that make BitKeeper so powerful) are available, using BitKeeper is arguably much more destructive than it is useful.
    • "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."

      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 h

  • Although there are no hard numbers, the estimates are that Linus has been 10x more productive with BK.

    No, it's that *everyone* was just 10x more productive after everyone stopped arguing about the whole matter.

    just kidding. If BK really helps the kernel dev's, all power to them. I havn't looked at the BK website in a year or so, but one thing I think i didn't like was having to connect to the internet every couple of days if using the unregistered version. while I understand the concept, it's just a bit
  • by galonso ( 705202 ) on Tuesday May 11, 2004 @02:50PM (#9119277)
    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


  • arch? (Score:4, Interesting)

    by dash2 ( 155223 ) <davidhughjones.gmail@com> on Tuesday May 11, 2004 @02:52PM (#9119286) Homepage Journal
    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?
    • Re:arch? (Score:5, Informative)

      by IamTheRealMike ( 537420 ) on Tuesday May 11, 2004 @03:16PM (#9119529)
      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.

  • by Omega1045 ( 584264 ) on Tuesday May 11, 2004 @02:52PM (#9119287)
    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.
  • "...the estimates are that Linus has been 10x more productive with BK." Does that mean we have a new unit of measurement for benchmarking?
  • support monotone (Score:5, Interesting)

    by trance9 ( 10504 ) on Tuesday May 11, 2004 @03:00PM (#9119381) Homepage Journal
    The monotone [venge.net] project needs developers to create a free software tool solving the same problem. We really do need good tools that are free.
  • by proxima ( 165692 ) on Tuesday May 11, 2004 @03:06PM (#9119439)
    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.
  • If it is true that bitkeeper makes him ten times more productive, then he must have spent more 90% of his time in the tool he used previously (was it RCS?).

  • by skink1100 ( 259238 ) on Tuesday May 11, 2004 @03:06PM (#9119444)
    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
  • by cduffy ( 652 ) <charles+slashdot@dyfis.net> on Tuesday May 11, 2004 @03:07PM (#9119447)
    That's not to say that BitKeeper is the only way to get that effect, however. GNU Arch [gnuarch.org] 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. :)
  • by goldspider ( 445116 ) on Tuesday May 11, 2004 @03:09PM (#9119466) Homepage
    ...need to justify himself to the Slashdot crowd?

    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.

  • by Anonymous Coward
    And for the rest of us who enjoy using free software, there's the Subversion [tigris.org] (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.
  • That's only 6.3X more productive in Imperial Productivity Units.
  • by norwoodites ( 226775 ) <pinskia@ g m a il.com> on Tuesday May 11, 2004 @03:13PM (#9119502) Journal
    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.
  • Subversion Anyone? (Score:3, Interesting)

    by cornice ( 9801 ) on Tuesday May 11, 2004 @03:18PM (#9119547)
    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?
    • by Eric Smith ( 4379 ) *
      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
  • Testing Expertise (Score:5, Insightful)

    by barryfandango ( 627554 ) on Tuesday May 11, 2004 @03:21PM (#9119565)

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

  • by kroah ( 751 ) on Tuesday May 11, 2004 @03:43PM (#9119774) Homepage Journal
    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.
  • Linus - Practical (Score:5, Insightful)

    by MisterFancypants ( 615129 ) on Tuesday May 11, 2004 @03:47PM (#9119818)
    The fact that Linus tends to choose pragmatism over idealism is why the Linux kernel is important and GNU hurd is completely still-born.

    Idealism is nice and all but it doesn't get shit done.

    • by al.cx ( 732497 ) *
      What a bullshit argument. So I guess GCC, Emacs, Bash and the hundreds of other GNU tools that make up the bulk of most Linux distributions are "still-born"?

      And for another example of idealism providing great tools via a slightly different ideology, see OpenBSD. Take a look at what they've done with PF and CARP. Neither development would've seen the light of day if it hadn't been for the OpenBSD group's free (BSD) software ideology.
  • by Anonymous Coward on Tuesday May 11, 2004 @03:47PM (#9119823)
    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 [somanetworks.com], and that's why I really wish we used it at Alias [alias.com]. 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
  • by The Pim ( 140414 ) on Tuesday May 11, 2004 @04:06PM (#9119985)
    Larry used to like to joust [iu.edu] 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" [abridgegame.org], which has some novel algorithms [abridgegame.org] for distributed revision control (I admit I don't understand them all, not being a physicist).
  • What went wrong? (Score:4, Insightful)

    by Trogre ( 513942 ) on Tuesday May 11, 2004 @06:00PM (#9121128) Homepage
    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.

He has not acquired a fortune; the fortune has acquired him. -- Bion

Working...