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.
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.
There's a old low-res video (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.
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.
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.
> I spent time and ran tests.
Ok? Share 'em. The scale I'm talking about is ginormous though. (Roughly: multiple GBs, 100k+ files & probably 250k+ commits in history).
For all I know it could be state-of-the-art performance for the scale, but repeat tasks taking minutes is still bad news.
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?
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!
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.
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.
https://news.ycombinator.com/item?id=26204218#26205688 (2021)