Comments on: Choosing a new version control system

by: Mike Kramlich

Mon, 26 May 2008 02:42:16 +0000

My favorite currently is git.
In the past I’ve used CVS, Subversion, Perforce, ClearCase and AccuRev and they all sucked in various ways.
Git basically just does version tracking on a file tree.
All of Git’s persisted history & metadata about your tracked file tree lives under a single .git subdir that hangs off the root of the tree. There is no central repository or other file magic, no hanging chads or dot-file seeds, etc.
It’s easy to use. As an example, once Git is installed, you can literally pull down the current official Linux kernel trunk in a single CLI invocation, with no previous setup steps necessary. Subsequent refreshes (pulls) are also that easy.
Git also has the advantage that it’s of the distributed flavor of VCS’s so very friendly for open source projects or distributed/global employees; it’s become the official one for Linux; and it’s lightning fast in the most common use cases for developers since it’s all about running small processes locally and talking to a local filesystem. So the problems of a client/server or centralized/remote architecture go away. There are no locking/in-use problems between concurrent users, for example.
Git seems to be one of the faster systems, due to it’s architecture.
Also, if you don’t trust it’s developer (Linus) to create a VCS to put your golden eggs into, then you probably shouldn’t be using Linux either. (Though it’s a much younger codebase, of course, so beware.)
I can’t speak to how well it handles binary files.
I have not used Mercurial, Bazaar, Darcs or Arch, so I can’t say if git is better or worse than any of those. A rough initial glance at them did not impress me enough to look closer, unlike git. Some Googling will uncover several in-depth comparisons and benchmarking in this area.

by: FooBat

Fri, 23 May 2008 23:02:40 +0000

Mercurial makes sense. I don’t see how Bazaar can even be considered for projects with larger repositories or more history. Even using Bazaar on its own repository is painfully slow. A pull to update a clone of bzr.dev took well over 6 hours for me–for a <100MB repository! In the same time, I had time to update git, linux-kernel, and mercurial clones, rebuild them, make dinner, and write some code.

by: bastiand

Thu, 22 May 2008 19:11:47 +0000

Nice post. The mercurial eclipse plugin has seen quite some enhancements, recently. So I'd like to invite you to try it and give us some hints, which are the biggest roadblocks for you when using it :-).

Bastian

by: David Roussel

Wed, 14 May 2008 15:07:51 +0000

ahh!

If you get the captca wrong you lose your comment!!!!

Again, but shorter:

looking forward to part 3
agree about the architectural vision. hg has it, git has it (for the lowwe, pluming, layers), but bzr doesn't. Maybe I haven't read enoght about bzr.
how did you get on with the merging in hg? How did you do you merging on windows?

by: tonyg

Wed, 07 May 2008 12:15:24 +0000

Liam, have you tried TortoiseHg? How do you find it, if so?

by: Paul Crowley

Sun, 04 May 2008 17:10:28 +0000

Tony: sure, but representations in VCSs are hard to change, especially the network protocol. Some binary formats can be merged with special tools, but only if the VCS can defer merging to external executables, which again runs entirely contrary to the spirit of darcs.

I'd like to see Mercurial (and/or Bazaar I guess) adopt something like darcs's approach to history-aware cherry picking, but retain the binary approach to storage and transmission and use the darcs algorithms only at merge time.

by: Liam Clancy (metafeather)

Sat, 03 May 2008 13:24:03 +0000

Great article Paul, look forward to the next one.

We are currently adopting Mercural too, but have a lot invested in Subversion - particularly in training for non-techies to get the version control bug thanks to TortoiseSVN, although part of the company is still using CVS as well.

I'd be very interested in how you migrate away from Subversion and/or how you find ways to maintain both repositories side by side especially in reusing your existing tools.

The MercurialPlugin for Trac has eased our pain and there appears possibilities for DVCS of an existing SVN workarea:

http://trac.edgewall.org/wiki/TracMercurial http://www.selenic.com/mercurial/wiki/index.cgi/WorkingWithSubversion

by: tonyg

Thu, 01 May 2008 15:18:08 +0000

Delta-compression is a pretty important feature, I agree, but really only for space-saving: it’s a representation issue rather than a semantic issue, if you see what I mean. No matter the system, binary files are treated as blobs (diff & merge over binaries not being a realistic option?). Darcs could add delta compression to its repository- and network-format and it wouldn’t change the way the system worked at all.

by: Paul Crowley

Thu, 01 May 2008 13:57:37 +0000

Darcs and binary files: see

http://wiki.darcs.net/DarcsWiki/FrequentlyAskedQuestions#head-f475693ac8dd4af9a381aad47b3c9dc90d6d7a32 and this thread: http://osdir.com/ml/version-control.darcs.user/2004-07/msg00018.html

Darcs stores binary files as hex, and does not attempt to delta-compress them at all, which could be painful on network bandwidth. As I said, the storage and network format is fundamentally based on patches which are fundamentally only meaningful on line-oriented text files.

Tom: I'm very interested to hear about the advantages of Bazaar over Mercurial; deciding between those two was as I said the most arbitrary part of the decision.

by: Tom Berger

Wed, 30 Apr 2008 22:19:03 +0000

For obvious reasons*, I'm quite curious to hear more about what led you to choose Mercurial over Bazaar.

You only mention two criteria:

...clearest architectural vision...

I find it hard to think that this is the case, but, either it's true (in which case the bzr folks should work on focusing their 'architectural vision') or it isn't (in which case they should work on better PR). What in particular made you think that Mercurial's architectural vision is clearer?

projects which I felt would be good at making good choices, such as Java and Coyotos

Setting aside the paradox of Java choosing a system written in a language other than Java (and with a radically different architectural vision too!), I'm pretty sure that most big projects (like Java, Coyotos, Mozilla) that have chosen Mercurial over Bazaar did so because at the time, hg had better performance for extremely large trees, and despite the fact that bzr had many other clear advantages. Meanwhile bzr improved a lot without compromising many of its process and architecture goals (turns out they were right about premature optimization after all). 99% of users (and LShift probably being inside these) shouldn't suffer from these performance problems, and definitely don't today, with the latest versions of bzr.

If you don't feel like posting in more detail here, or sending something to the bzr mailing list, I wouldn't mind chatting about this (I don't hope to convince you, and Mercurial is not a bad choice, just want to learn a thing or two).

Also, I won't bother listing here what are, IMHO, the clear advantages of bzr, but ask if you're interested.

Tom

disclosure: the commenter is employed by Canonical, the company sponsoring bzr.