7 ms·

Oddly, both Bazaar, Git and Mercurial were created around March/April 2005. Why the sudden appearance of popular DVCSs around that time, and why did Bazaar fall

by Aqwis 13y ago

Oddly, both Bazaar, Git and Mercurial were created around March/April 2005. Why the sudden appearance of popular DVCSs around that time, and why did Bazaar fall behind the other two in popularity?

zobzu 13y ago
git is used by a bigger project (the kernel), that's mainly why. they're all ok, otherwise, even with their technical differences. github also contributed to amplify the adoption as its makes it really easy to use (even thus people generally use git in a non-distributed way with github) (i do prefer git in usage, tho, but thats subjective i suppose)
- DigitalJack 13y ago
  for me it's the easy branching and rebasing that make git the winner. That's in spite of the inconsistent cli. If Hg were as good at branching and rebasing, I'd reconsider it. btw, anyone know of a python command line client for git? I just keep finding stuff for programmatically using git and that's not what I want.
  - lmm 13y ago
    What do you mean, a python command line client? If you're using it from the command line and not programmatically, why does it matter what language it's written in? (gitless may possibly be what you want)
    - pritambaral 13y ago
      It matters if you want to hack on it.
    - DigitalJack 13y ago
      portability
  - peacetara 13y ago
    http://www.samba.org/~jelmer/dulwich/ http://www.samba.org/~jelmer/dulwich/
    - DigitalJack 13y ago
      Thanks!
- krakensden 13y ago
  And Xorg, and Samba, and Wine, and a bunch of other projects. In retrospect, people overestimate github's impact, I think. "Fast enough for big projects like the kernel" was a big deal.
iv_08 13y ago
Canonical mismanagement, contributor license agreement, missing manpower.
- rlpb 13y ago
  The article and the quite detailed bzr history it links to do not appear to suggest this at all. Can you provide any justification for your three claims?
  - bronson 13y ago
    License Agreement: the first paragraph in the section "Hard to land patches" describes the CLA as one reason why it's hard. Missing manpower: just glance at the mailing list archives.
  - bronson 13y ago
    Actually, sources for all three statements can be found within 2 paragraphs (moving forward and backward) of "Decline and focus on Ubuntu and UDD"
Skinney 13y ago
I think it was due to the free version of bitkeeper (which the Linux kernel used for vcs) was taken off market. So the Linux devs would either have to pay for a DVCS or make their own... Several made their own, Git was chosen for the kernel, alot of people found uses for the others. I could be wrong, but I think that's the case.
- andyjohnson0 13y ago
  There never was a free version. BitMoover Inc provided free BitKeeper licences to the Linux kernel devs. This was unpopular because of the non-FOSS nature of Bitkeeper. Andrew Tridgell [1] at OSDL became frustrated with some aspects of the software and reverse-engineered its network protocol to develop his own limited client. This caused BitMoover to revoke the licences used by OSDL, which in turn provoked Linus Torvalds (who was at OSDL) to develop the early version of Git. [2] [1] http://en.wikipedia.org/wiki/Andrew_Tridgell http://en.wikipedia.org/wiki/Andrew_Tridgell [2] http://en.wikipedia.org/wiki/BitKeeper#Pricing_change http://en.wikipedia.org/wiki/BitKeeper#Pricing_change
- graywh 13y ago
  In 2005, there were already some free, open-source DVCSs. Linus considered using Monotone for the Linux kernel project before deciding to start Git.
drunken_thor 13y ago
If you read the article included in the post it says that git, mercurial and bazaar all came together because Bitkeeper stopped being free. Now as for why bazaar didnt get used so much even when supported by canonical is a mystery to me.
- icefox 13y ago
  I'm surprised he didn't mention GitHub. You can't ignore the luck that the guys that made GitHub used Git.
gizmogwai 13y ago
All of them emerged due to the end of license agreement for a free license of bitkeeper for the linux kernel. Git won due mainly to Linus personnality and the rise of "social coding" via github. Bazaar failed because, at the beginning, it was painfully slow compare to git and mercurial. It speed has increase over time, but bad reputation is hard to get rid of.
- sillysaurus2 13y ago
  All of them emerged due to the end of license agreement for a free license of bitkeeper for the linux kernel. Bet bitkeeper regretted that decision...
  - twoodfin 13y ago
    If I recall, the zeitgeist then was that bitkeeper was a necessary evil. My guess is that git would have come into being eventually in any circumstances short of bitkeeper becoming free software, and maybe even then. Distributed change management is such a critical component of the kernel development process (especially for Linus and the other maintainers) that relying on someone else's software seems suboptimal.
    - frenchy 13y ago
      The reason Bitkeeper dropped the kernel was that certain kernel devs had started writing free software to interact with the kernel repository (they wanted to be able to perform certain tasks that bitkeeper couldn't). Had this continued, we would probably have ended up seeing a free version of Bitkeeper.
  - justincormack 13y ago
    They don't seem to have updated their website since http://www.bitkeeper.com/ http://www.bitkeeper.com/
- jwr 13y ago
  I'd say git is popular not just because of Linus, but also because it is oriented towards "just getting stuff done", rather than towards theoretical concepts. You can rewrite history, fix your mistakes, and generally do whatever you want. When merging, git isn't picky, either: if the code looks the same, it is the same. In-place branching is hugely useful, just switch your tree in an instant (your editor should update the contents of your files automatically). So is the stash. Overall, it's just a useful tool that doesn't try to teach you "how things should theoretically be done", and never says "well in order to get X, you should have done this a long time ago".
praptak 13y ago
This is what happened, basically a huge "I told you so, proprietary software blows." for the Stallmans of this world: http://www.theregister.co.uk/2005/04/14/torvalds_attacks_tridgell/ http://www.theregister.co.uk/2005/04/14/torvalds_attacks_tri...
- michaelt 13y ago
  This is excellent trolling material because you can argue in both directions: It proves proprietary software can't be trusted; and at the same time it proves Open Source is all about free knockoffs of innovations made in proprietary software.
  - deleted 13y ago
    [deleted]
baq 13y ago
people need just one DVCS. it was slow and when it finally got fast, it didn't matter, because everybody was happily using the alternatives.
__david__ 13y ago
Git won the popularity war because the Linux kernel used it and then Github pushed it mainstream. Frankly, Bzr never got as popular as Git and Hg because it just isn't as good. It's slow, has a bizarre (sorry) branching model, and came out of Baz and Arch which were downright terrible (to be fair, Bzr shares no code and was designed as a rewrite to jettison all the stupidness of Baz and Arch—nonetheless it is tainted by being related to them).
- eloisant 13y ago
  Actually I think Github got popular because it was Git, not the other way around. At the time it appeared people just wanted to have git repos, Github was there, so they used it.
  - rbanffy 13y ago
    Confirming that, Bitbucket added git support because they saw Mercurial as not competitive with Git.
    - agwa 13y ago
      But only after Git became wildly popular because of GitHub.
  - agwa 13y ago
    There wasn't a demand for Git repos any more than there was a demand for Hg repos. For instance, open source projects moving away from SVN seemed to be pretty evenly distributed between Git and Hg. The real demand was for a way to publish code and collaborate, and GitHub provided a truly innovative approach (the social aspects, encouraging forking and pull requests) that was miles better than the alternatives (SourceForge was already in decline, Google Code didn't have the social/forking/pull request aspects). I think they would have been successful with any distributed VCS. I always preferred Git, so I'm happy they chose Git, but I think that if they had chosen Hg, we'd be talking about how Hg won the popularity war instead of Git.
midas007 13y ago
Cambrian explosion followed by consolidation. Git and Mercurial were Linux affiliated. In the end, when apps are similar and don't have fatal flaws, it comes down to a popularity contest.
- quotemstr 13y ago
  > Cambrian explosion followed by consolidation. The term is "adaptive radiation", of which the Cambrian explosion is a prominent example. (Unrelated but awesome note: search for "edicarian biota" to look at some body plans that might have won, but didn't.)
rlpb 13y ago
One thing that git wins for me is interoperability. git's format-patch, send-email, apply and am subcommands make it very easy to interoperate with others using plain text patches on mailing lists for code review, etc. At this stage, isn't a "bzr vs. git vs. hg" question at all. It's just "look, it's a patch". I think this ease and ability to work losslessly with plain text patches gives git a clear advantage over bzr. This functionality makes it really easy for people who don't know git to interoperate with people who know it. Lossless interoperability with plain text is a key Unix principle (see TAOUP) and something that bzr lacks. With bzr, everybody involved with a project must use bzr. OTOH, a project that uses git can work more easily with a whole spectrum of people since sending a simple patch to a mailing list provides exactly the same ease of workflow to git-using developers as a complex multi-stage set of changes that is heavily reviewed and modified before being committed. (I don't know hg well enough to understand how it fits in here)
- dded 13y ago
  I'm entirely ignorant of bzr, but I've got to say that this surprises me. We use svn, which certainly works well with patch.
  - rlpb 13y ago
    To the extent that svn works with patch, so does bzr, and so does git. What I'm talking about is lossless integration with entire patch sets in the form that git does it with format-patch, send-email and am.
    - kzrdude 13y ago
      git patch support is more feature complete. Atomic application by default and using parent information for three-way merge to apply patches if requested.
anonymouz 13y ago
Adding a bit of history to the other comments: Bazaar is actually a successor to an earlier DVCS, called Gnu Arch (or Tom Lord's Arch, TLA, at some point). It started out in 2001 and was, I believe, the first of the DVCS crowd. It had some idiosyncrasies, but was a huge step up from CVS in terms of its principles. tla was forked into baz (previously Bazaar), and bzr (previously Bazaar-NG) was a rewrite taking into account lessons learned from tla/baz. Darcs is yet another DVCS inspired partly by Gnu Arch. So while the explosion of new DVCS around 2005 can definitely be traced back to the Bitkeeper incident, I believe the seed for modern DVCS was laid a bit earlier, in 2001, with Tom Lord's Arch. I think Gnu Arch/tla is to be credited with originally introducing many of the concepts of distributed version control. Of course, if anyone knows of earlier history on distributed VCS or a VCS that isn't in some way a spiritual successor to TLA I would be quite interesting in knowing that.
- cjp 13y ago
  Here [1] is a good but necessarily incomplete summary of version control tool history, written by ESR. Tom Lord does deserve much credit for DVCS concepts, but so do Larry McVoy (Bitkeeper) and Graydon Hoare (Monotone). [1] http://www.catb.org/esr/writings/version-control/version-control.html#history http://www.catb.org/esr/writings/version-control/version-con...
  - abrahamsen 13y ago
    I'd give Larry McVoy most credit of the three. He worked at TeamWare, which was the first DVCS, at least the first I have heard of. I don't know how much credit goes to him specifically, compared to the other people who worked on TeamWare though. http://en.wikipedia.org/wiki/Sun_WorkShop_TeamWare http://en.wikipedia.org/wiki/Sun_WorkShop_TeamWare

by Aqwis 13y ago

Oddly, both Bazaar, Git and Mercurial were created around March/April 2005. Why the sudden appearance of popular DVCSs around that time, and why did Bazaar fall behind the other two in popularity?

zobzu 13y ago

git is used by a bigger project (the kernel), that's mainly why. they're all ok, otherwise, even with their technical differences. github also contributed to amplify the adoption as its makes it really easy to use (even thus people generally use git in a non-distributed way with github) (i do prefer git in usage, tho, but thats subjective i suppose)

DigitalJack 13y ago
for me it's the easy branching and rebasing that make git the winner. That's in spite of the inconsistent cli. If Hg were as good at branching and rebasing, I'd reconsider it. btw, anyone know of a python command line client for git? I just keep finding stuff for programmatically using git and that's not what I want.
- lmm 13y ago
  What do you mean, a python command line client? If you're using it from the command line and not programmatically, why does it matter what language it's written in? (gitless may possibly be what you want)
  - pritambaral 13y ago
    It matters if you want to hack on it.
  - DigitalJack 13y ago
    portability
- peacetara 13y ago
  http://www.samba.org/~jelmer/dulwich/ http://www.samba.org/~jelmer/dulwich/
  - DigitalJack 13y ago
    Thanks!
krakensden 13y ago
And Xorg, and Samba, and Wine, and a bunch of other projects. In retrospect, people overestimate github's impact, I think. "Fast enough for big projects like the kernel" was a big deal.

iv_08 13y ago

Canonical mismanagement, contributor license agreement, missing manpower.

rlpb 13y ago
The article and the quite detailed bzr history it links to do not appear to suggest this at all. Can you provide any justification for your three claims?
- bronson 13y ago
  License Agreement: the first paragraph in the section "Hard to land patches" describes the CLA as one reason why it's hard. Missing manpower: just glance at the mailing list archives.
- bronson 13y ago
  Actually, sources for all three statements can be found within 2 paragraphs (moving forward and backward) of "Decline and focus on Ubuntu and UDD"

Skinney 13y ago

I think it was due to the free version of bitkeeper (which the Linux kernel used for vcs) was taken off market. So the Linux devs would either have to pay for a DVCS or make their own... Several made their own, Git was chosen for the kernel, alot of people found uses for the others. I could be wrong, but I think that's the case.

andyjohnson0 13y ago
There never was a free version. BitMoover Inc provided free BitKeeper licences to the Linux kernel devs. This was unpopular because of the non-FOSS nature of Bitkeeper. Andrew Tridgell [1] at OSDL became frustrated with some aspects of the software and reverse-engineered its network protocol to develop his own limited client. This caused BitMoover to revoke the licences used by OSDL, which in turn provoked Linus Torvalds (who was at OSDL) to develop the early version of Git. [2] [1] http://en.wikipedia.org/wiki/Andrew_Tridgell http://en.wikipedia.org/wiki/Andrew_Tridgell [2] http://en.wikipedia.org/wiki/BitKeeper#Pricing_change http://en.wikipedia.org/wiki/BitKeeper#Pricing_change
graywh 13y ago
In 2005, there were already some free, open-source DVCSs. Linus considered using Monotone for the Linux kernel project before deciding to start Git.

drunken_thor 13y ago

If you read the article included in the post it says that git, mercurial and bazaar all came together because Bitkeeper stopped being free. Now as for why bazaar didnt get used so much even when supported by canonical is a mystery to me.

icefox 13y ago
I'm surprised he didn't mention GitHub. You can't ignore the luck that the guys that made GitHub used Git.

gizmogwai 13y ago

All of them emerged due to the end of license agreement for a free license of bitkeeper for the linux kernel. Git won due mainly to Linus personnality and the rise of "social coding" via github. Bazaar failed because, at the beginning, it was painfully slow compare to git and mercurial. It speed has increase over time, but bad reputation is hard to get rid of.

sillysaurus2 13y ago
All of them emerged due to the end of license agreement for a free license of bitkeeper for the linux kernel. Bet bitkeeper regretted that decision...
- twoodfin 13y ago
  If I recall, the zeitgeist then was that bitkeeper was a necessary evil. My guess is that git would have come into being eventually in any circumstances short of bitkeeper becoming free software, and maybe even then. Distributed change management is such a critical component of the kernel development process (especially for Linus and the other maintainers) that relying on someone else's software seems suboptimal.
  - frenchy 13y ago
    The reason Bitkeeper dropped the kernel was that certain kernel devs had started writing free software to interact with the kernel repository (they wanted to be able to perform certain tasks that bitkeeper couldn't). Had this continued, we would probably have ended up seeing a free version of Bitkeeper.
- justincormack 13y ago
  They don't seem to have updated their website since http://www.bitkeeper.com/ http://www.bitkeeper.com/
jwr 13y ago
I'd say git is popular not just because of Linus, but also because it is oriented towards "just getting stuff done", rather than towards theoretical concepts. You can rewrite history, fix your mistakes, and generally do whatever you want. When merging, git isn't picky, either: if the code looks the same, it is the same. In-place branching is hugely useful, just switch your tree in an instant (your editor should update the contents of your files automatically). So is the stash. Overall, it's just a useful tool that doesn't try to teach you "how things should theoretically be done", and never says "well in order to get X, you should have done this a long time ago".

praptak 13y ago

This is what happened, basically a huge "I told you so, proprietary software blows." for the Stallmans of this world: http://www.theregister.co.uk/2005/04/14/torvalds_attacks_tridgell/ http://www.theregister.co.uk/2005/04/14/torvalds_attacks_tri...

michaelt 13y ago
This is excellent trolling material because you can argue in both directions: It proves proprietary software can't be trusted; and at the same time it proves Open Source is all about free knockoffs of innovations made in proprietary software.
- deleted 13y ago
  [deleted]

baq 13y ago

people need just one DVCS. it was slow and when it finally got fast, it didn't matter, because everybody was happily using the alternatives.

__david__ 13y ago

Git won the popularity war because the Linux kernel used it and then Github pushed it mainstream. Frankly, Bzr never got as popular as Git and Hg because it just isn't as good. It's slow, has a bizarre (sorry) branching model, and came out of Baz and Arch which were downright terrible (to be fair, Bzr shares no code and was designed as a rewrite to jettison all the stupidness of Baz and Arch—nonetheless it is tainted by being related to them).

eloisant 13y ago
Actually I think Github got popular because it was Git, not the other way around. At the time it appeared people just wanted to have git repos, Github was there, so they used it.
- rbanffy 13y ago
  Confirming that, Bitbucket added git support because they saw Mercurial as not competitive with Git.
  - agwa 13y ago
    But only after Git became wildly popular because of GitHub.
- agwa 13y ago
  There wasn't a demand for Git repos any more than there was a demand for Hg repos. For instance, open source projects moving away from SVN seemed to be pretty evenly distributed between Git and Hg. The real demand was for a way to publish code and collaborate, and GitHub provided a truly innovative approach (the social aspects, encouraging forking and pull requests) that was miles better than the alternatives (SourceForge was already in decline, Google Code didn't have the social/forking/pull request aspects). I think they would have been successful with any distributed VCS. I always preferred Git, so I'm happy they chose Git, but I think that if they had chosen Hg, we'd be talking about how Hg won the popularity war instead of Git.

midas007 13y ago

Cambrian explosion followed by consolidation. Git and Mercurial were Linux affiliated. In the end, when apps are similar and don't have fatal flaws, it comes down to a popularity contest.

quotemstr 13y ago
> Cambrian explosion followed by consolidation. The term is "adaptive radiation", of which the Cambrian explosion is a prominent example. (Unrelated but awesome note: search for "edicarian biota" to look at some body plans that might have won, but didn't.)

rlpb 13y ago

One thing that git wins for me is interoperability. git's format-patch, send-email, apply and am subcommands make it very easy to interoperate with others using plain text patches on mailing lists for code review, etc. At this stage, isn't a "bzr vs. git vs. hg" question at all. It's just "look, it's a patch". I think this ease and ability to work losslessly with plain text patches gives git a clear advantage over bzr. This functionality makes it really easy for people who don't know git to interoperate with people who know it. Lossless interoperability with plain text is a key Unix principle (see TAOUP) and something that bzr lacks. With bzr, everybody involved with a project must use bzr. OTOH, a project that uses git can work more easily with a whole spectrum of people since sending a simple patch to a mailing list provides exactly the same ease of workflow to git-using developers as a complex multi-stage set of changes that is heavily reviewed and modified before being committed. (I don't know hg well enough to understand how it fits in here)

dded 13y ago
I'm entirely ignorant of bzr, but I've got to say that this surprises me. We use svn, which certainly works well with patch.
- rlpb 13y ago
  To the extent that svn works with patch, so does bzr, and so does git. What I'm talking about is lossless integration with entire patch sets in the form that git does it with format-patch, send-email and am.
  - kzrdude 13y ago
    git patch support is more feature complete. Atomic application by default and using parent information for three-way merge to apply patches if requested.

anonymouz 13y ago

Adding a bit of history to the other comments: Bazaar is actually a successor to an earlier DVCS, called Gnu Arch (or Tom Lord's Arch, TLA, at some point). It started out in 2001 and was, I believe, the first of the DVCS crowd. It had some idiosyncrasies, but was a huge step up from CVS in terms of its principles. tla was forked into baz (previously Bazaar), and bzr (previously Bazaar-NG) was a rewrite taking into account lessons learned from tla/baz. Darcs is yet another DVCS inspired partly by Gnu Arch. So while the explosion of new DVCS around 2005 can definitely be traced back to the Bitkeeper incident, I believe the seed for modern DVCS was laid a bit earlier, in 2001, with Tom Lord's Arch. I think Gnu Arch/tla is to be credited with originally introducing many of the concepts of distributed version control. Of course, if anyone knows of earlier history on distributed VCS or a VCS that isn't in some way a spiritual successor to TLA I would be quite interesting in knowing that.

cjp 13y ago
Here [1] is a good but necessarily incomplete summary of version control tool history, written by ESR. Tom Lord does deserve much credit for DVCS concepts, but so do Larry McVoy (Bitkeeper) and Graydon Hoare (Monotone). [1] http://www.catb.org/esr/writings/version-control/version-control.html#history http://www.catb.org/esr/writings/version-control/version-con...
- abrahamsen 13y ago
  I'd give Larry McVoy most credit of the three. He worked at TeamWare, which was the first DVCS, at least the first I have heard of. I don't know how much credit goes to him specifically, compared to the other people who worked on TeamWare though. http://en.wikipedia.org/wiki/Sun_WorkShop_TeamWare http://en.wikipedia.org/wiki/Sun_WorkShop_TeamWare