Dabbling in distributed version control

The new workplace uses Subversion for version control. That’s cool. I know Subversion. It works, and it’s well-supported everywhere.

For ages, though, I’ve been wanting to try out distributed version control systems, but except for putting a few personal projects (which no one else is working on, defeating much of the purpose) in git, I haven’t had the chance. Now I do! Support for pushing to Subversion repositories is almost a requirement to get a new DVCS off the ground.

Work is in C# in Visual Studio on Windows. Supporting those things is helpful too.

Choices come down to [Git](http://git-scm.com/), [Mercurial](http://www.selenic.com/mercurial/wiki/) (hg) and [Bazaar](http://bazaar-vcs.org/) (bzr):

### Git ###

Linus Torvalds coded this up on a weekend to deal with the Linux kernel source. With lots of other projects signing on, it looks like it might win as the standard on Linux at least…

##### Advantages ####

* I’ve started using it for stuff on Linux.
* Fast and space-efficient.
* A friend has been using it for a while, and I’d like to work with him on stuff one of these days.

##### Disadvantages #####

* Subversion integration doesn’t work in the latest Windows release.

### Mercurial ###

I actually know very little about it. [Joel](http://www.joelonsoftware.com) says it’s what they use at FogCreek…

##### Advantages #####

* Good Windows support.
* Most mature [Visual Studio integration](http://sharesource.org/project/visualhg/wiki/) (not saying much).

##### Disadvantages #####

* I find the terminology a bit odd…
* Subversion support is [confusing and/or alpha-ish](http://www.selenic.com/mercurial/wiki/index.cgi/WorkingWithSubversion).

### Bazaar ###

Popularized by the Ubuntu project, bzr seems less user-hostile than the others. I’m only really looking into it seriously now.

##### Advantages #####

* I like Ubuntu and it’s made by the same guys.
* Canonical actually cares about usability.
* Subversion support is simple and well-integrated.
* Windows support is good.
* Dedicated to inter-operating with other systems.

##### Disadvantages #####

* No Visual Studio support (yet).

So none give me exactly what I want. I think bzr is the closest, though.

As an aside, the [Ankh SVN 2.0](http://blogs.open.collab.net/svn/2008/07/ankhsvn-20-fina.html) Visual Studio integration is actually really good. A little rough around the edges, but still surprisingly good. I’m kinda sad I didn’t hear about it back when it came out in July. It would’ve made my life a lot simpler.

A good Visual Studio integration is the one thing that’s holding me back from diving straight into bzr and using it for work. I’m debating whether automatically tracking adds, drops and moves trumps being about to work on my own branch without having to tell the server about it.

5 thoughts on “Dabbling in distributed version control”

  1. I vote Bazaar, but then again, I don’t need Visual Studio integration…

    Also, my needs aren’t that strenuous… so it fits pretty well.

    Tried Mercurial for a bit, but didn’t like it.

    Need Windows support, so Git never really entered into the picture… (It’s probably come quite a way, but it seemed REALLY rooted in Linux the last time I looked…)

    Best of luck!

  2. I just had a crash course in Subversion today. (First day on the job!)

    Perl5 has just moved from Perforce to Git. The long version numbers (sha hashes) are causing some (mostly visual) issues. Turns out you can truncate the number in most places.

  3. Congrats on finding a job! :D

    I wouldn’t have thought you’d have to deal with the SHA1 hashes very much. Unless you’re trying to do something in git that you used to do with Perforce… We ran into people like that at my old job, who came from CVS and thought you had to obsessively tag everything all the time…

    Git’s quite a bit better on Windows now, but the unsupportedness of git-svn and the general hackishness of the whole thing was kind of a turnoff. I took a look into the APIs a bit and left with a bit of a bad taste.

    Bzr is nice. I think I’ll stick with that.

  4. I gotcha. I’m talking about people who get stuck in one version control paradigm having weird expectations when they move to another. As far as I can tell, the answer to being put off by long, sha1 hash strings for version numbers is you probably never actually need to refer to version numbers. Particularly in a distributed system.

Comments are closed.