Article: Distributed Version Control Systems
Since Linus Torvalds presentation at Google about git in May 2007, the adoption and interest for Distributed Version Control Systems has been constantly rising. In this article, Sebastien Auvray introduces the concept of Distributed Version Control, see when to use it, why it may be better than what you’re currently using, and have a look at three actors in the area: git, Mercurial and Bazaar.
Sebastien start out by comparing Distributed Version Control Systems with Centralized VMS:es:
Or a more precise question: Why Central VCS (and notably Subversion) are not satisfying? Several things are blamed on Subversion:
* Major reason is that branching is easy but merging is a pain (but one doesn't go without the other). And it's likely that any consequent project you'll work on will need easy gymnastic with splits, dev, test branches. Subversion has no History-aware merge capability, forcing its users to manually track exactly which revisions have been merged between branches making it error-prone.
* No way to push changes to another user (without submitting to the Central Server).
* Subversion fails to merge changes when files or directories are renamed.
* The trunk/tags/branches convention can be considered misleading.
* Offline commits are not possible.
* .svn files pollute your local directories.
* svn:external can be harmful to handle.
* Performance
After that, Sebastien moves on to describe how DVCS works, which the open source options are, before he comes to the an excellent comparison between git, Mercurial and Bazaar. The comparison includes things line features, model, web access, integration, performance, hosting options and many other things.
If you’re having trouble deciding which DVCS to pick, this is the article for you.
/filters:no_upscale()/sponsorship/topic/f1e73882-f385-4f4f-89e2-0799e364e183/CockroachRSB-1684221636780.jpg)
/articles/devex-metrics-framework/en/smallimage/DevEx-a-New-Metrics-Framework-small-1683887713694.jpg)
/articles/mental-health-well-being-remote-hybrid/en/smallimage/making-time-for-our-mental-health-small-1682693206026.jpg)
/presentations/organizations-evolve-work/en/smallimage/Jennifer Davis-s-1681717407074.jpg)
/presentations/hybrid-one-on-one/en/smallimage/Alexandra-Sunderland-s-1681716650317.jpg)
/articles/visual-thinking/en/smallimage/LOGO-1679339789328.jpg){kind=logo}
/articles/group-coaching-beyond-individual/en/smallimage/group-coaching-extending-growth-opportunity-beyond-individual-coaching-small-1671614956735.jpg)
/articles/secure-delivery-workflow/en/smallimage/logo-1675435091128.jpg){kind=logo}
/articles/tester-machine-leaning-project/en/smallimage/LOGO-1676401530402.jpg){kind=logo}
![[R]Evolutionize Your Retrospectives with Active Sensemaking](https://imgopt.infoq.com/fit-in/50x50/filters:quality(80)/articles/retrospectives-active-sensemaking/en/smallimage/revolutionize-your-retrospectives-with-active-sensemaking-small-1684227204199.jpg)
/articles/manager-building-remote-teams/en/smallimage/logo-1682334615101.jpg){kind=logo}
/articles/culture-trends-2023/en/smallimage/InfoQ-Trend-Report-logo-1680287660356.jpeg){kind=logo}
/articles/rebuild-tech-culture-layoffs/en/smallimage/how-to-rebuild-tech-culture-for-those-who-survived-the-layoffs-small-1677236107330.jpg)
/articles/architecture-architecting-role/en/smallimage/logo-1670404086277.jpg){kind=logo}
/articles/tech-stack-not-meeting-needs/en/smallimage/your-tech-stack-doesnt-do-what-everyone-needs-it-to-small-1674818401120.jpg)
/articles/team-level-metrics-matter/en/smallimage/LOGO-1673637433912.jpg){kind=logo}
/articles/future-technology-talent/en/smallimage/logo-1670326001370.jpg){kind=logo}
/articles/agility-architecture/en/smallimage/logo-1682078942739.jpg){kind=logo}
/articles/api-design-review/en/smallimage/API-design-reviews-are-dead-long-live-API-design-reviews-small-1684310900854.jpg)
/articles/architecture-modernization-domain-driven-discovery/en/smallimage/start-your-architecture-modernization-with-domain-driven-discovery-small-1683106490819.jpg)
/articles/architecture-trends-2023/en/smallimage/the-infoq-trends-report-1680611416202.jpeg)
/articles/framework-architectural-decisions/en/smallimage/logo-1679060242842.jpg){kind=logo}
/articles/istio-ambient-mesh/en/smallimage/logo-1678364642232.jpg){kind=logo}
/articles/effective-architecture-conversations/en/smallimage/have-effective-conversations-with-business-stakeholders-about-software-architecture-small-1677231728391.jpg)
/articles/creating-decentralized-apps/en/smallimage/LOGO-1676916574942.jpg){kind=logo}
/presentations/data-streams-architecture/en/smallimage/Kai_Waehner-s-1675025271514.jpg)
/articles/energy-consumption-bugs/en/smallimage/logo-1673281703209.jpg){kind=logo}
/articles/motivational-diagnostic/en/smallimage/increasing-team-and-individual-motivation-with-motivational-diagnostic-small-1672932888794.jpg)
/articles/architecture-skeptics-guide/en/smallimage/a-skeptics-guide-to-software-architecture-decisions-small-1672223516348.jpg)
/minibooks/2022-infoq-trends-reports/en/smallimage/LOGO-1672051527011.jpg){kind=logo}
/articles/platform-engineering-roadmap/en/smallimage/logo-1670836548184.jpg){kind=logo}
/articles/software-testing-energy-management/en/smallimage/logo-1670618011406.jpg){kind=logo}
/presentations/lyft-cd-benefits-challenges/en/smallimage/tom-wanielista-small-1685002834068.jpg)
Community comments
Issue Tracker Integration for git
by Roman Heinrich,
Excellent article
by Surya De,
Kind of....
by chris songer,
Re: Kind of....
by Sebastien Auvray,
Re: Kind of....
by sax maniac,
Outstanding breakdown
by Kurt Christensen,
my 2c
by Bela Babik,
BitKeeper
by Robert Sullivan,
SVK - Subversion decentralized - http://svk.bestpractical.com/view/HomePage
by Ludolph Neethling,
Rebase plugin available for Bazaar
by Jelmer Vernooij,
Re: Rebase plugin available for Bazaar
by Sebastien Auvray,
Top mark against Subversion going away
by Ray Davis,
git repository size
by dhamma vicaya,
SVK
by Seurin Jean,
Usability/colour impairment
by Damien Warman,
Article Updated
by Sebastien Auvray,
Good but...
by David H.,
Choices
by Bruno Vernay,
Update on Bazaar performance
by Ian Clatworthy,
Branches in Hg are supported
by Stepan Koltsov,
MySQL uses Bazaar
by Robin St,
history model
by bgeron bgeron,
Re: history model
by Bhaskar Rimal,
Re: history model
by Sebastien Auvray,
Re: history model
by bhaskar rimal,
Revision naming in Mercurial
by Dirkjan Ochtman,
Re: Revision naming in Mercurial
by Mark Anderson,
You forgot git-bisect.
by John Q. Public,
Issue Tracker Integration for git
by Roman Heinrich,
Your message is awaiting moderation. Thank you for participating in the discussion.
Git integrates well with Readmine (www.redmine.org/), a Rails-based Issue Tracker. Just had to add this one ;)
Excellent article
by Surya De,
Your message is awaiting moderation. Thank you for participating in the discussion.
I thoroughly enjoyed this. And I learned a lot from this as well. Somehow our switch from CVS to Subversion makes less sense now after reading this.
Kind of....
by chris songer,
Your message is awaiting moderation. Thank you for participating in the discussion.
The problem with this analysis, and those like it, is that they assume SVN as the state of the art. SVN is the state of the "free" art; but is missing a lot of features that perforce offers.
Now Perforce is pretty costly, but when broadly comparing "centralized vs. decentralized" it's probably not quite on target to use the "best free" rather than the "best." Many of the issues cited (and thereby implied to be issues with centralized solutions)
For example, perforce does not pollute your directories with control files. Perforce does a fantastic job of maintaining merges between branches and keeping merge history.
Indeed, most of the arguments put forward against "central" tend to be limitations in the SVN implementation of centralized SCM rather than limitations in the state of the art.
Outstanding breakdown
by Kurt Christensen,
Your message is awaiting moderation. Thank you for participating in the discussion.
Dude, this was a very, very nice article. Thanks for the rollup.
Re: Kind of....
by Sebastien Auvray,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hi Chris,
I agree with you that Perforce got some good points that SVN do not support. But as you said 1) you need to pay for it 2) you really need to take a big care of your production scalability (as any central server...) else it's becoming a big bottleneck and you're blocked at each branch creation... Some Editors like Idea add some intelligence to that like adding the Offline mode.
my 2c
by Bela Babik,
Your message is awaiting moderation. Thank you for participating in the discussion.
DVCS's are young, but very capable. They are rather tools not systems to manage the code. Users need to come up with their own workflow and thats what a lot of them do not get.
It can be frustrating when someone tries out one of them and it seems complicated after CVS/SVN. The benefits are not so obvious (what are the benefits for a developer who has never ever did any branching and merging in CVS/SVN?).
> Mercurial SLOC (without Test src)
Mercurial's core is python + c only (there are 4 c files).
What I don't like about Git:
- is that it is a mess. c+perl+bash
- my environment is polluted by it really hardly (at least in msys git, there are huge amount of aliases)
- native windows port is really far from being production ready. (I can not even use it from behind firewall.)
What I don't like about Mercurial:
- tree handling is not really good. It's not an easy call to implement it right, but it is important.
- editing of the history is considered harmful and not really supported (can be done though through extensions, but not as nice as in git)
What I like about Mercurial:
- hgbook is awesome
- easy to extend (the included extensions are good starting point)
- clean python
- very flexible, you can build nice workflows around it
- mq is evil but very handy once you understand what and how is it doing
BitKeeper
by Robert Sullivan,
Your message is awaiting moderation. Thank you for participating in the discussion.
Great article, nice comparison & research. I've been very interested in BitKeeper and git since reading about the controversy with Linux. Very cool idea, and if anyone's interested there is some very good doc out there explaining how BitKeeper works.
And I find it amazing that when Larry McEvoy pulled the plug on the Linux licenses, Linus (or someone) shook git out of their sleeve in a short time. Impressive.
Now that said, Torvalds has an incredible knack for saying incredibly insulting comments. SVN is pointless? When 59% of git users also use SVN or CVS? and anyone who uses CVS is stupid - uh - this coming from someone who didn't use *any* version control until forced to do so because it was impacting the work on Linux? Now that was nuts. Now, SCM is a given, CVS is probably one of the grandaddy, we stand on the shoulders of giants. And SVN's aim was to fix issues with CVS, nothing more, isn't git pretty much a clone of BitKeeper, like Linux a clone of Unix? Hopefully for Linus, the successors to Linux will have a more admirable view of their forebearers.
SVK - Subversion decentralized - http://svk.bestpractical.com/view/HomePage
by Ludolph Neethling,
Your message is awaiting moderation. Thank you for participating in the discussion.
Thanks for the informing article. Another option for a DVCS maybe SVK. I haven't tried it myself, so feedback or a review of SVK would be appreciated.
Copied from wikipedia:
"SVK (also written svk) is a decentralized version control system written in Perl, with a hierarchical distributed design comparable to centralized deployment of BitKeeper and GNU arch.
SVK uses the Subversion filesystem but provides additional features:
* Offline operations like checkin, log, merge.
* Distributed branches.
* Lightweight checkout copy management (no .svn directories).
* Advanced merge algorithms, like star-merge and cherry picking.
* Changeset signing and verification.
* Can mirror and operate on Subversion, Perforce and CVS repositories."
I do think it addresses some of the problems of subversion, but seeing I haven't used it I don't know what new problems it creates.
Regards,
Rebase plugin available for Bazaar
by Jelmer Vernooij,
Your message is awaiting moderation. Thank you for participating in the discussion.
Your overview lists Bazaar as not having support for Rebase and queues. However, there is a rebase plugin available for Bazaar ( bazaar-vcs.org/Rebase) and a queues one (launchpad.net/bzr-loom).
Re: Rebase plugin available for Bazaar
by Sebastien Auvray,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hi Jelmer,
You're right, I'll update this asap.
I'll also take into consideration some interesting remarks from reddit.
Thanks.
Top mark against Subversion going away
by Ray Davis,
Your message is awaiting moderation. Thank you for participating in the discussion.
Nice overview, thanks. One thing, though -- the "major reason" you list for moving from Subversion is the difficulty of merging, but history-aware merge is the major improvement being delivered in Subversion 1.5. That's mentioned in the pages you link to at the end of your article, but given the importance attached to the feature, I thought it might be worth calling out.
git repository size
by dhamma vicaya,
Your message is awaiting moderation. Thank you for participating in the discussion.
git gc by default uses a conservative window size to save memory. For relatively large import from foreign repositories you should run:
git repack -a -f -d --window=100 --depth=100
A couple of times until the repository doesn't get any smaller.
SVK
by Seurin Jean,
Your message is awaiting moderation. Thank you for participating in the discussion.
Being a novice in the matter, I'd be very interested in having some feedback on how SVK compare to the mentioned DVCS.
I had identified it as a potential solution to solve my SVN problems, mainly off-line commits and .svn file.
I'm very happy for the new perspectives the articles gave me. Thanks for the hard work!
Usability/colour impairment
by Damien Warman,
Your message is awaiting moderation. Thank you for participating in the discussion.
This otherwise rather interesting article is for me and for more than 10% of readers fatally undermined by the choice to use generic icons differing only in red/green colour choice in the first comparison table. Simple check/dash/x symbology, or even a tooltip, would dramatically increase its usefulness.
Article Updated
by Sebastien Auvray,
Your message is awaiting moderation. Thank you for participating in the discussion.
[Article updated on 20080512 according to the comments here and from Ian Clatworthy and reedit]:
Good but...
by David H.,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hello.
A nice article, but I am a bit disappointed. First of all there is no mention of www.monotone.ca/ which is a well recognised DVCS now-a-days. It also fails to mention that git traditionally is fastest because on linux good old Linus Torvalds is using all the low level filesystem tricks you can possibly think off.
Choices
by Bruno Vernay,
Your message is awaiting moderation. Thank you for participating in the discussion.
@Perforce : That's why Open Source (and free beer) is relevant : you get considered.
Developer's choices are not based on which is best, but what is my community using, as the author noticed :
But overall, the point is that your SCM tool should support your workflow and processes. It maybe be easier to change the tool than it is to change the processes.
Update on Bazaar performance
by Ian Clatworthy,
Your message is awaiting moderation. Thank you for participating in the discussion.
My measurements have 'bzr clone master feature-1' coming in around 22 secs. A patch is available to reduce this to 16 secs. See this email for further details.
If you want to save further time and space when cloning in Bazaar, use the --hardlink option. It cuts the time to 11.2 secs (vs 11.1 secs for git on my computer) and reduces space usage across the working trees, which is where most of the disk space get consumed in tools as efficient at historical storage as these.
Branches in Hg are supported
by Stepan Koltsov,
Your message is awaiting moderation. Thank you for participating in the discussion.
Seems like branches are supported in hg:
hgbook.red-bean.com/hgbookch8.html
MySQL uses Bazaar
by Robin St,
Your message is awaiting moderation. Thank you for participating in the discussion.
There's now a big project which decided to use Bazaar, namely MySQL. Here's the announcement.
history model
by bgeron bgeron,
Your message is awaiting moderation. Thank you for participating in the discussion.
Sorry, but the history model for Mercurial is the same as for Git and Bazaar. A changeset/changegroup/commit/revision is in all systems a name for a snapshot. :)
Re: history model
by Bhaskar Rimal,
Your message is awaiting moderation. Thank you for participating in the discussion.
This is very impressive article and good analysis.Actually I want to know could anyone can explain about DVCS by UML diagram of its every process and steps so that I can understand all its micro process as visually.
Re: history model
by Sebastien Auvray,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hi Bhaskar,
It's very difficult to gather information on the micro process from the various VCS available. I can only advise you Scott Chacon presentation about Git at RailsConf and its slides.
Re: history model
by bhaskar rimal,
Your message is awaiting moderation. Thank you for participating in the discussion.
Thank you very much
Revision naming in Mercurial
by Dirkjan Ochtman,
Your message is awaiting moderation. Thank you for participating in the discussion.
There's been some confusion among people who think Mercurial doesn't use SHA1 for revision identification, because this article suggests its naming is simpler. While we gladly accept the notion that our revision identification scheme is simpler to use than that of other DVCSs, it's still fundamentally based on SHA1 hashes. Please note this in the table, if you can.
Re: Revision naming in Mercurial
by Mark Anderson,
Your message is awaiting moderation. Thank you for participating in the discussion.
As much as I appreciated articles like this in the past, I must say we did ourselves a favor by skipping the interim solution of going from CVS and VSS to another open source tool and chose what we believe is the last tool we'll have to use, period. www.accurev.com I just don't get what all the excitement is over a 'free' tool that will only lead to more problems down the road?
You forgot git-bisect.
by John Q. Public,
Your message is awaiting moderation. Thank you for participating in the discussion.
Generally a very good article. But...
Widely considered one of Git's killer features, git-gisect is worth mentioning.
Basically, it automates searching through the revision history for a version that introduced a regression. Git's speed lets you make frequent small commits, so the change that introduced the regression can be very small, and the result is the problem is easy to spot.
For distributed development, it's particularly nice because it lets even a relatively unskilled tester find the exact commit that introduced the regression and send the complaint straight to the relevant developer.
(It has, of course, been copied by Hg and bzr, so it's no longer unique to git. Still something well worth knowing about.)
Re: Kind of....
by sax maniac,
Your message is awaiting moderation. Thank you for participating in the discussion.
But centralization is the main weakness of Perforce - you cannot work while you are offline as you need to check out files on the server, which is unneeded and annoying. That is why SVN beats Perforce (from developer point of view).