4 ms·

Hmm no mention of Mercurial which was also released around the same time as Git and IIRC was also a contender for Linux kernel development VCS. Larry McVoy bas

Hmm no mention of Mercurial which was also released around the same time as Git and IIRC was also a contender for Linux kernel development VCS. Larry McVoy basically forced the creation of Git via Andrew Tridgell and look where we are today - while world uses Git. Larry must have had his reasons but I wonder how he feels about the outcome.

sydthrowaway 4y ago
https://news.ycombinator.com/item?id=9330482 https://news.ycombinator.com/item?id=9330482
- kzzzznot 4y ago
  Interestingly about a year after that conversation BitKeeper was made open source
  - stevekemp 4y ago
    For completeness here's where that was discussed: https://news.ycombinator.com/item?id=11667494 https://news.ycombinator.com/item?id=11667494
  - cryptonector 4y ago
    At some point you realize that you can no longer monetize some proprietary code you have. Now what? You basically have two options: let it die, or open source it. Pride dictates that you'll want to open source it. In the world of infrastructure software, you have to keep moving forward because open source will replace your proprietary infrastructure software eventually. Stay still, milk that cow, and you'll lose the cow. It's that simple. Or better yet: develop a solid open source monetization plan to begin with. Not that that's easy! But D. Richard Hipp managed. Thinking about it, why couldn't BK have been the SQLite3 of DVCS? The answer is probably that McVoy didn't think about the SQLite model, probably because SQLite was the first to succeed at it, and that came after the BK->Git migration, or at least the realization that SQLite had a great business model came later. To recap, the SQLite model is this: a) make a great open source project, b) make a proprietary test suite for it with 100% branch coverage, c) convince the world that (b) exists, d) let them come to you for features and bug fixes, e) form a consortium to get paid through. BK coulda been a contendah!
    - zoomablemind 4y ago
      >...To recap, the SQLite model is this: a) make a great open source project, b) make a proprietary test suite for it with 100% branch coverage, c) convince the world that (b) exists, d) let them come to you for features and bug fixes, e) form a consortium to get paid through. Where does this recap come from? My understanding was that SQLite was initially created in a context for a client that needed assurances of correctness, thus the extensive testing suite. As for the revenue, there's a proprietary extension to support fully encrypted db and access. This is licensed and supported.
      - cryptonector 4y ago
        > Where does this recap come from? Is it not true? > My understanding was that SQLite was initially created... Ah, you think I meant that that was the SQLite model on day 1. But no, I meant that this is what it became. > As for the revenue, there's a proprietary extension to support fully encrypted db and access. This is licensed and supported. Consortium membership costs money. That money pays for the dev team.
- password4321 4y ago
  Every time he pops in he gets asked about this, apparently... https://news.ycombinator.com/item?id=26204218#26205688 https://news.ycombinator.com/item?id=26204218#26205688 (2021)
ptha 4y ago
From the article: In 2005, Andrew tried to reverse-engineer the BitKeeper networking protocols in order to create a free software alternative. If it hadn't been him, it would've been someone else—it was only a matter of time. Larry McVoy had warned the Linux developers that he would pull the plug if anyone tried this, and that's exactly what he did. Some speculation, but is there a chance that Tridgell was aware of MyVoy's condition on the use of BitKeeper as source control for the Linux Kernel and attempted the reverse-engineering deliberately to force the scenario where the development of an Open Source BitKeeper alternative was necessary?
deleted 4y ago
[deleted]
tanepiper 4y ago
Around that time I (and a couple of others) worked on the excitingly named hgfront (https://github.com/tanepiper/hgfront https://github.com/tanepiper/hgfront) which was a Mercurial frontend a little like GitHub. There's a old low-res video (https://www.youtube.com/watch?v=NARcsoPp4F8 https://www.youtube.com/watch?v=NARcsoPp4F8) of it in action. I really liked Mercurial and used BitBucket for a while, but in the end GitHub won out.
- indrora 4y ago
  I'd argue that GH won over Bitbucket because of two key factors: 1. It wasn't developed by Atlassian, who at the time had a reputation for building more unwieldy tools (Jira, anyone?) and had a weird, awkward feel. The fact that Git had gained near instantaneous traction and Bitbucket needed you to learn Mercurial made it a near non-starter. 2. GitHub's model ("Social Coding") and zero-effort force amplification made it just the right wedge. Git had terrible tooling on the frontend and GitHub providing "Just enough" tooling around the server side while also providing the right kinds of tooling (webhooks, enterprise-ish features, click-to-fork, a very good PR path, etc) made it easy to use Git. Mercurial might be the "superior" tool from certain standpoints but Git had a few tricks up its sleeve that made people like it: * Written in C. No extra runtimes. * Modular construction: `git-slap` is immediately available as `git slap` like a native tool. * Performance of Mercurial was bad on massive codebases and slower machines. I mean terrible. once you hit 500KLOC or into the 2MLOC, a simple merge could take minutes if not tens of minutes in the old days if you weren't on a fairly modern (2005-7ish) machine. If you'd kept your slightly older P2 laptop around, you were absolutely roasting under the weight of what took Git mere seconds.
  - i_like_apis 4y ago
    Mercurial performance is still terrible for large codebases.
    - skinnymuch 4y ago
      Someone said it is their job to keep HN a nice place. I will try to follow suit. Could you provide citations or evidence to such a claim? In following HN guidelines, I did not do a quick dismissal. I spent time and ran tests. I do not see the same conclusions. I am ready to post up some data in good faith.

sydthrowaway 4y ago

https://news.ycombinator.com/item?id=9330482 https://news.ycombinator.com/item?id=9330482

kzzzznot 4y ago
Interestingly about a year after that conversation BitKeeper was made open source
- stevekemp 4y ago
  For completeness here's where that was discussed: https://news.ycombinator.com/item?id=11667494 https://news.ycombinator.com/item?id=11667494
- cryptonector 4y ago
  At some point you realize that you can no longer monetize some proprietary code you have. Now what? You basically have two options: let it die, or open source it. Pride dictates that you'll want to open source it. In the world of infrastructure software, you have to keep moving forward because open source will replace your proprietary infrastructure software eventually. Stay still, milk that cow, and you'll lose the cow. It's that simple. Or better yet: develop a solid open source monetization plan to begin with. Not that that's easy! But D. Richard Hipp managed. Thinking about it, why couldn't BK have been the SQLite3 of DVCS? The answer is probably that McVoy didn't think about the SQLite model, probably because SQLite was the first to succeed at it, and that came after the BK->Git migration, or at least the realization that SQLite had a great business model came later. To recap, the SQLite model is this: a) make a great open source project, b) make a proprietary test suite for it with 100% branch coverage, c) convince the world that (b) exists, d) let them come to you for features and bug fixes, e) form a consortium to get paid through. BK coulda been a contendah!
  - zoomablemind 4y ago
    >...To recap, the SQLite model is this: a) make a great open source project, b) make a proprietary test suite for it with 100% branch coverage, c) convince the world that (b) exists, d) let them come to you for features and bug fixes, e) form a consortium to get paid through. Where does this recap come from? My understanding was that SQLite was initially created in a context for a client that needed assurances of correctness, thus the extensive testing suite. As for the revenue, there's a proprietary extension to support fully encrypted db and access. This is licensed and supported.
    - cryptonector 4y ago
      > Where does this recap come from? Is it not true? > My understanding was that SQLite was initially created... Ah, you think I meant that that was the SQLite model on day 1. But no, I meant that this is what it became. > As for the revenue, there's a proprietary extension to support fully encrypted db and access. This is licensed and supported. Consortium membership costs money. That money pays for the dev team.
password4321 4y ago
Every time he pops in he gets asked about this, apparently... https://news.ycombinator.com/item?id=26204218#26205688 https://news.ycombinator.com/item?id=26204218#26205688 (2021)

ptha 4y ago

From the article: In 2005, Andrew tried to reverse-engineer the BitKeeper networking protocols in order to create a free software alternative. If it hadn't been him, it would've been someone else—it was only a matter of time. Larry McVoy had warned the Linux developers that he would pull the plug if anyone tried this, and that's exactly what he did. Some speculation, but is there a chance that Tridgell was aware of MyVoy's condition on the use of BitKeeper as source control for the Linux Kernel and attempted the reverse-engineering deliberately to force the scenario where the development of an Open Source BitKeeper alternative was necessary?

deleted 4y ago

[deleted]

tanepiper 4y ago

Around that time I (and a couple of others) worked on the excitingly named hgfront (https://github.com/tanepiper/hgfront https://github.com/tanepiper/hgfront) which was a Mercurial frontend a little like GitHub. There's a old low-res video (https://www.youtube.com/watch?v=NARcsoPp4F8 https://www.youtube.com/watch?v=NARcsoPp4F8) of it in action. I really liked Mercurial and used BitBucket for a while, but in the end GitHub won out.

indrora 4y ago
I'd argue that GH won over Bitbucket because of two key factors: 1. It wasn't developed by Atlassian, who at the time had a reputation for building more unwieldy tools (Jira, anyone?) and had a weird, awkward feel. The fact that Git had gained near instantaneous traction and Bitbucket needed you to learn Mercurial made it a near non-starter. 2. GitHub's model ("Social Coding") and zero-effort force amplification made it just the right wedge. Git had terrible tooling on the frontend and GitHub providing "Just enough" tooling around the server side while also providing the right kinds of tooling (webhooks, enterprise-ish features, click-to-fork, a very good PR path, etc) made it easy to use Git. Mercurial might be the "superior" tool from certain standpoints but Git had a few tricks up its sleeve that made people like it: * Written in C. No extra runtimes. * Modular construction: `git-slap` is immediately available as `git slap` like a native tool. * Performance of Mercurial was bad on massive codebases and slower machines. I mean terrible. once you hit 500KLOC or into the 2MLOC, a simple merge could take minutes if not tens of minutes in the old days if you weren't on a fairly modern (2005-7ish) machine. If you'd kept your slightly older P2 laptop around, you were absolutely roasting under the weight of what took Git mere seconds.
- i_like_apis 4y ago
  Mercurial performance is still terrible for large codebases.
  - skinnymuch 4y ago
    Someone said it is their job to keep HN a nice place. I will try to follow suit. Could you provide citations or evidence to such a claim? In following HN guidelines, I did not do a quick dismissal. I spent time and ran tests. I do not see the same conclusions. I am ready to post up some data in good faith.