I feel like I’m constantly falling behind on stuff I want to post about but don’t get around to. One of which is the version control system Mercurial I have been using now for almost 4 months and loving ever since.
Since Google just decided to enable Mercurial on Google Code I figured it’s a great time to write about it.

What is Mercurial?
I’ll quote the getting started article from Bitbucket:

Introduction

Mercurial is a distributed version control system, or DVCS for short. It is in the ranks of Git and Bazaar, leading a new paradigm of working with version control.

Philosophy

This new paradigm of distributed versioning allows for several things that centralized development does not. Specifically, it provides:

1. Allows commits/logs even when working offline
2. Drastic increase in speed for most operations
3. Ability for anyone to have their own copy of a project, and continue work without explicit "commit access"
4. No requirement to publish changes
5. No need to set up a server for version controlling things (self-contained)

So, it’s like your  own private version control system. Nobody can mess with it, you own it.
Which is great, I mean: How often has a fellow coworker submitted something to your tree that made your code break? Or how often did you update before a commit just to see that the update breaks something (and your changes weren’t commited, so you’re at the mercy of merges)?

What also rocks is it’s simplicity. Mercurial needs no server, so even on my little pet projects I can leverage the power of a SCM system without the headache around setting up something in a central place.

What most people though fail to understand is that the centralized model does also mean that you need to share your private changes with the world at some time.
And while doing so on a shared filesystem is very easy (when sharing with a coworker for example), doing so over the wire is non-trivial as it would require you setting up a server somewhere.

And that’s how I learned to love Bitbucket:

Bitbucket's aim is to compensate for this while maintaining the flexibility and benefits of DVCS. It does this firstly by providing a centralized location for a repository which provides a sharing-point for one or more developers to grow their code base. Secondly, it provides a set of tools that ease development and sharing of a code with the rest of the world.

Bitbucket is free and gives you 150mb of disk space, an issue tracker and a wiki for each of your projects. While the limitation is that only one project/repository per account can be private (not open source), there is no limit on how many public repositories you can create.

I suggest reading the guides on Bitbucket (or the book) on how HG differs from SVN and how the usual workflow looks like.
Also I suggest installing TortoiseHg, this will install all the hg command-line as well as a nice shell integrated GUI like we are all used to from TortoiseSVN.

I encourage every one (even single developers) to use a Sourcecontrol system such as SVN and AnkhSVN to do development. Put all your project files (and external dependencies) under source control and maybe even get a continuous integration server setup.

And still, even if you’ve done all of this, chances are high you still have one external dependency in your project: the Database!

And this is where the pain starts, if you don’t find some way how to put your DB schema under source control too, you’ll end up going back to old versions and having no database of that date.

There are however several ways to solve this that I can think of:

• Make your CI server fetch a schema script every time a build is triggered.
• Make creating a schema script part of your build process

And .. guess what? There’s a simpler way :).
If you’re using a ORM tool you should always have your database model somewhere in the mapping files.

Because the mapping files tell the ORM the structure of the DB, they essentially contain all relevant information needed to generate a schema without the need to have SQL scripts.

In NHibernate for example, you can simply do a:

var cfg = new Configuration();
cfg.Configure();
cfg.AddAssembly(typeof (Person).Assembly);

new SchemaExport(cfg).Execute(false, true, false, false);

And the mapper will go out and create all necessary tables and relationships in your database.

By having an ORM capable of recreating the schema, I no longer need to keep the Database itself under source control, because the necessary information to recreate the schema is already in my source tree.

After playing around with Log4Net and the Castle MicroKernel, I suddenly discovered that not having those external dependencies under source control makes development quite difficult.

Whenever I update my dependencies, all other people on the team need to adjust theirs to match mine and vice versa. This is a minor annoyance while the team is small, once you grow and have people coming in and out of the team you’ll start to feel real pain!

If sucks even more if you’ve already shipped your application and get called a year later to change something. Trust me, digging up the right version of library X isn’t getting easier over time, and updating the application to a new version may either break the application or cause your customers to update too (both highly undesired!).

So, what’s the right solution to dependencies?
(No it’s not reinventing the wheel over and over again by writing everything by yourself)

Simple: Put the dependencies into a folder called /lib/ and reference them from there, set the “Copy To Output Directory” option to “Copy if newer”.
Then add this folder to your source control and you’re set. Whenever a new guy comes to the team and gets the project from source control, he’s guaranteed to be able to build it without having to run around some random site searching for referenced assemblies.

I complained before that Visual Studio has no built in support for Subversion, as SVN is currently one of the most common source control choices for open source projects.

One commenter pointed me towards AnkhSVN as a source control provider, but I wasn't working on anything involving SVN so I didn't install AnkhSVN right away - I should have done!

AnkhSVN 2.0 is exactly what I was looking for!
I installed it and it integrated itself very nicely with Visual Studio. Not acting as a AddIn but as a source control provider similar to Visual Source Safe.

So it hooks itself into your solution explorer, showing you the file status within Visual Studio

You can open projects directly from Subversion, and the Pending Changes window helps in keeping track of what changes need to be committed to the SVN (never forget to commit your .csproj file after adding files to your project ;)).

Overall, AnkhSVN works very well and the UI is clean and does what you'd expect from your Subversion client, and it's good integration into Visual Studio helps. No more exception list hacking for file-based clients like Tortoise SVN.

As with most open source software, AnkhSVN is still work in progress, and I've already found some bugs. But if this project continues to evolve I think we have a really powerful tool at our hands!

So, if you want to try it for yourself (strongly suggested), go and grab the latest release (I suggest installing the daily build) from the AnkhSVN project site.
If you find any bugs while using the tool, please make sure to tell the developers. Their issue tracker sucks, you'll need to register and request access to the tracker (but they are pretty fast in granting access).