In the day job, we use TFS as our source control system. It's officially blessed, and will be supported Real Soon Now. Until then, we're stuck on a crummy pilot version that falls over pretty frequently. Most people down tools when this happens.

However, there does seem to be a way forward. I use one of the new breed of distributed source control systems to continue working locally while the main source control server is down. I happen to have picked Mercurial (due to Windows support) but in theory this approach should work with any source control system which doesn't require a central repository. You get that sense of safety once more, that you can change code, roll back, and version. In fact, I can tag a version that I will eventually want to get reviewed and check into TFS as a changeset, and then continue working on it.

Note that this solution simply lets you continue working locally, safely. If you don't have the files that you need to hand before your departmental source control server falls over, then you're stuck. Obviously you won't be able to commit back to it, either. And if (like TFS) your source control system fiddles with client-side state (file permissions, etc.) then you will probably have to fix that all up when your source control server does come back online.

So how do you do it?

First of all, download and install Mercurial, and initialise your workspace as a Mercurial repository:

> cd path\to\workspace
> hg init

That creates a Mercurial repository in your current directory. Next, add and commit all the existing files to give you a starting point:

> hg add *
> hg commit -m "Initial commit"

Now you can go ahead and make your changes. Remember that you'll have to hg add and hg del any added and removed files.

When you get to the point where you would normally check in to TFS, just make a tag:

> hg tag -m "Tests now pass" tests-pass

You can now go ahead and continue making more changes, tagging each time you'd normally check in.

The TFS server is back!

Eventually, the TFS server (or whatever centralised source control system you use) will come back, and it's time to commit all the changes you've been working on.

First of all, commit and tag your final changes into the Mercurial repository as you have been doing before.

Now it's time to roll back the repository to each of your tags in turn, and commit into your TFS repository. First, get a list of all your commits to find out the tag names (there's probably a neater way of doing this, but I'm an hg novice!)

>hg log
changeset:   4:9a2bc8c4cd6e
tag:         tip
user:        dan
date:        Wed Aug 01 11:25:30 2007 +0100
summary:     Added tag BAR for changeset 4ed3893351e8

changeset:   3:4ed3893351e8
tag:         BAR
user:        dan
date:        Wed Aug 01 11:25:24 2007 +0100
summary:     added foobar

changeset:   2:46a175a2952b
user:        dan
date:        Wed Aug 01 11:24:51 2007 +0100
summary:     tagging

changeset:   1:129cee9d9958
tag:         FOO
user:        dan
date:        Wed Aug 01 11:24:36 2007 +0100
summary:     added world

Here you can see I created two tags, FOO and BAR. First bring the working copy back to the state it was for tag FOO (changeset 1):

> hg update -C FOO
0 files updated, 0 files merged, 2 files removed, 0 files unresolved

Commit that to TFS. Now bring your repository up to the next tag you made:

> hg update -C BAR
2 files updated, 0 files merged, 0 files removed, 0 files unresolved

Rinse, and repeat. And watch your colleagues' faces as you seem to be generating large amounts of code in a very short space of time!