1. 33
  1. 17

    Larry McVoy provided some context on HN for why they decided to open source bitkeeper:


    1. 14

      This could have been neat a decade ago…

      1. 5

        Still, its nice that its available today.

        1. 3

          Perhaps for historical context, or maybe for another example of how a good SCM works at the source code level, but why would anyone actually choose to use this when you’d just be encumbering new team members with Yet Another SCM?

      2. 8

        IIRC, Linux was kept in bk for a while before Linus got tired of it and wrote up git.

        How has BitKeeper progressed over time?

        What advantages does it have over git, bzr, darcs, Mercurial, etc.?

        1. 15

          Linux was in bk, under a no-cost closed-source license for the kernel devs. Bitkeeper prohibited attempts to clone/reverse engineer it. A dev reverse engineered it by telnetting to the server port and typing ‘help’. Bitkeeper revoked the license. Linus coded git in the next few weeks.

          1. 15

            Linus coded git in the next few weeks.

            Let’s not forget that hg was also released within a couple of weeks to replace bk.

            Writing a vcs within a few weeks isn’t a task that only Linus can do. ;-)


            1. 8

              Just to add more details, Linux was happy using bk. He worked in the same office as Andrew Tridgell. Andrew didn’t use bk and hadn’t agreed to no EULA. Andrew begun to reverse engineer the bk protocol (by sniffing network traffic in his office iirc). Linus asked him to stop doing it. He refused. Linus was forced to write git (and called Andrew and ass iirc)

              1. 3

                Any source for this?

                1. 9

                  This mostly lines up with stories I’ve heard from people that were present in the kernel community at the time, for what it’s worth. I’ve only ever gotten it as an oral history though, so I can’t really provide any concrete evidence beyond what JordiGH offers in terms of “search the LKML”.

                  1. 3

                    Most of the drama was public on mailing lists, but it’s kind of hard to find. Look at LKML around April 2005 and earlier.

                      1. 1

                        It’s mostly from memory from reading Slashdot and osnews at the time. The parts I’m not 100% certain have iirc next to it.

                  2. 4

                    The website has a “Why?” page that tries to answer some of those questions.

                    1. 11

                      BK/Nested allows large monolithic repositories to be easily broken up into any number of sub-repositories.

                      “I see you have a poorly structured monolith. Would you like me to convert it into a poorly structured set of micro services?” - Twitter