First, you should clone or pull the latest version of hgsubversion and update it to tip before you upgrade Mercurial. This is due to breaking changes in Mercurial’s internal API after hgsubversion 1.1 was released.

Second, there is a bug in hgsubversion, again due to breaking changes in the Mercurial API, that results in an exception when it is used with the bookmarks extension in version 1.6. I have implemented a fix for this in my own fork of hgsubversion, though at the time of writing this hasn’t yet made it back into the official repo.

(Update: this fix has now been merged into hgsubversion 1.2.2.)

Apart from that, everything seems to work reasonably enough. My initial tests seem to indicate that hg-git works fine with Mercurial 1.6. TortoiseHg 1.1 comes with Dulwich 0.6.0, so you can now safely update hg-git to the latest stable version (0.2.2) or to tip if you’re that way inclined.

For example, it is commonly believed that Git can track functions being moved from one file to another, and merge in the changes appropriately. It’s a plausible claim—I’m pretty sure that such a merge algorithm is doable—and it would also be particularly useful, since it would open up several more possibilities for the kind of refactoring that you can manage in a distributed workflow with parallel work streams.

Of course, this is very easy to test, so on Friday evening, I decided to test it.

I loaded the code for the latest version of my Comment Timeout WordPress plugin into a new git repository and created a branch called Alice. I then edited the file class.post-processor.php to add a comment in the constructor, and checked it in.

I then switched back to the original version and created a branch called Bob. I cut the constructor from class.post-processor.php and pasted it into class.comment-processor.php, and checked the resulting changes into Bob. I then attempted to merge Alice and Bob.

Lo and behold, I got a merge conflict.

Both Git and Mercurial support a merge-over-rename scenario which Subversion doesn’t: if Alice makes some edits to foo.txt and Bob renames it to bar.txt, Alice’s changes to foo.txt will be correctly merged into Bob’s bar.txt. I haven’t done any more exhaustive testing than that, but I suspect that Git and Mercurial have overall roughly similar merging capabilities, though undoubtedly there will be some edge cases that one handles that the other doesn’t, and vice versa.

It seems that the biggest difference is that Git uses various heuristics to automatically detect file renames, whereas Mercurial expects the user to flag them explicitly. Which approach is better is controversial, but Mercurial users who prefer Git’s behaviour in this respect may be interested in this experimental extension to detect and register obvious renames at commit time which I knocked together over the weekend.

First, to the gentleman who was at the rear of the central section of coach number eight in the 18:32 Southern train from London Victoria to Southampton Central and Bognor Regis this evening, who got off at Three Bridges.

Your favourite TV programme as a child may have been Top Cat. Your favourite TV programme as a thirty-something adult may still be Top Cat. You may think it’s cool to have the Top Cat theme tune as the ringtone on your mobile phone even though you’re in your thirties or forties. But when said mobile phone starts blaring out said ringtone at full volume in a train full of tired commuters for several minutes, it gets extremely annoying. Please, choose something less ingratiating.

Besides, what on earth were you smoking that you slept through a ringtone like that for nearly ten minutes? It must have been pretty potent.

Second, to whoever rang said gentleman no less than ten times round about 7pm this evening.

Unless your problem is genuinely important and genuinely urgent, ringing someone’s phone repeatedly when they don’t answer the first couple of times is rude. They may not be in a position to answer, and by calling them over and over and over and over again for several minutes, you are sending out a signal that you are a demanding, obnoxious type with no respect whatsoever for other people’s personal space. Just leave a message, and if they agree that it’s important, they’ll get back to you. Besides, you could be inflicting the theme tune to Top Cat on a train carriage full of tired commuters on their way home, because the person you’re calling is too non compos mentis to answer.

I’m going to get really controversial here and say that I think Mercurial is better than git. My reasoning (as with the reasoning of everyone else who takes sides in this particular debate) is entirely subjective, so we won’t belabour the point here too much. Nevertheless, some of us do have a preference for one over the other, and many Subversion refugees like me who do most of their work in Windows tend to lean towards Mercurial.

But there’s no denying that github is fast becoming the Facebook of open source programming (albeit hopefully without the unethical bits, Farmville, and people tagging you in embarrassing photos for all and sundry to see), and if you want to strut your stuff as a developer, that’s the place to do it. Github is, of course, a hosting facility for git repositories, as one would expect of a site whose name says what it means and means what it says.

Fortunately, it is quite possible to use Mercurial as a client against github repositories via the hg-git extension, and you can pull and push from one to the other pretty much losslessly.

However, setting it all up on Windows is not entirely straightforward, and there doesn’t seem to be a decent guide to it anywhere on the Internet: most of the instructions that you read assume that you’re using either (a) Linux or a Mac, (b) the command line, or (c) both. You also have to figure it out from various places all over the web, and searches on Google and Stack Overflow proved to be surprisingly fruitless. Furthermore, the most comprehensive howto that I came across elsewhere contained several instructions that were just plain wrong.

So, after spending two solid evenings struggling against a myriad of error messages and cryptic dialog boxes, I finally managed to get it working, and for future reference (and anyone else who wants to know how), I’ve documented what I’ve found actually works for me as best I can.

1. Install TortoiseHg and hg-git.

Install TortoiseHg 1.1 or later. If you are using an earlier version, upgrade: these instructions may work if you don’t, but I can’t make any guarantees.

I downloaded hg-git by cloning the repository. You can get it from either github and Bitbucket. The advantage of cloning the repository is that you can upgrade to the latest version quickly and easily by hg pull then hg update, or use the graphical tools if you prefer. You can also easily switch between the bleeding edge version of the code and a stable release if you like.

hg clone http://bitbucket.org/durin42/hg-git c:\abc\mercurial\hg-git

I downloaded hg-git into the directory c:\abc\mercurial\hg-git. If you put it elsewhere in your filespace, alter these instructions to suit.

2. Update to the appropriate version of hg-git.

If you are using TortoiseHg 1.1, you will need to use hg-git 0.2.3. If you ignored my advice to upgrade, and are still using version 1.0, you will need to use hg-git 0.2.1. Don’t use version 0.2.2: it doesn’t work with either version of TortoiseHg.

The official hg-git documentation tells us that we also need to download and install Dulwich 0.4.0 or later. The latest version of hg-git requires Dulwich 0.6.0. In any case, Dulwich is included with TortoiseHg (version 0.6.0 with TortoiseHg 1.1; version 0.5.0 with TortoiseHg 1.0) so you don’t need to do anything else there. Open up the TortoiseHg repository explorer on your clone of hg-git, choose the “Tagged” radio button to show only tagged releases, and update to version 0.2.3:

3. Configure Mercurial to use hg-git and an appropriate SSH client.

To do this, you need to edit your mercurial.ini file. You can get to this simply by choosing “Global Settings” on the TortoiseHg context menu in Windows Explorer, and clicking “Edit file” to bring it up in Notepad. Add the following lines to your configuration file:

[extensions]
hggit = C:\abc\mercurial\hg-git\hggit

[ui]
ssh = "C:\Program Files\TortoiseHg\TortoisePlink.exe"

The [extensions] section loads hg-git into Mercurial; the ssh option in the [ui] section specifies an SSH command line client to use to communicate with github. TortoiseHg gives us TortoisePlink, which works fine for me.

4. Create a public key/private key pair.

There are some instructions on github on how to create a public key/private key pair. Unfortunately, these don’t tell you that key pairs come in two formats: OpenSSH (as used by git itself and github), and PuTTY (as used by Tortoise Everything).

A simpler approach is to download PuTTY (you can get it from here) and use PuTTYgen to generate your key pair:

Once you have generated your SSH key, copy and paste the “Public key for pasting into OpenSSH authorized_keys file” into github. Save your public key and private key to your hard disk somewhere.

5. Start Pageant

Pageant is a program that stores all your private keys in memory, where the SSH client used by Mercurial, that we configured above, can find them. It comes with both PuTTY and TortoiseHg. You can set it to load in your private key(s) when you log on to Windows by creating a new shortcut in the Startup folder of your Start menu with this command:

"C:\Program Files\TortoiseHg\Pageant.exe" "c:\abc\github.ppk"

Note that if you don’t start Pageant first and load in your private key, you will not be able to push to github.

6. Clone a repository and start pushing!

You should make sure that you get the format of your repository URL correct. It should be:

git+ssh://git@github.com/your-github-username/your-repo-name.git

The rest from there on is all plain sailing. All being well, you should now be able to pull from your github repository and push changes back up as if it were a Mercurial repository.

Things to check if it goes wrong.

Now all this is a bit of a fiddly process, there is plenty of room for error, and some of the error messages you are likely to get can be a little bit cryptic. However, most of it was due to me trying things that weren’t properly documented, and they all boiled down to a few things that you can check if you’ve followed the above instructions:

• Are you using the correct version of hg-git? While you can use versions later than 0.2.1, you need to use a later version of Dulwich than that which comes with TortoiseHg 1.0.
• The “ssh” option in your mercurial.ini file should only specify the name of the executable, without command line options. Some articles tell you that you can fill in the path to your private key in this option. Personally, I couldn’t get this to work, so I just stuck with Pageant.
• Is Pageant running?
• Is your private key loaded into Pageant?
• Do your public and private keys match?
• Is your private key saved in PuTTY format? If you generated your key pair using git, as per the instructions on github, it will be saved in OpenSSH format instead, and Pageant can’t handle that.¹
• Have you specified the URL to your github repository correctly? The version I gave above works, while missing out various parts of the URL (e.g. using “github.com” instead of “git@github.com“) doesn’t.

-----BEGIN RSA PRIVATE KEY-----
<transmission line noise>
-----END RSA PRIVATE KEY-----

PuTTY-User-Key-File-2: ssh-rsa
Encryption: none
Comment: imported-openssh-key
Public-Lines: 6
<transmission line noise>
Private-Lines: 14
<transmission line noise>
Private-MAC:
<transmission line noise>

New Scientist, meanwhile, reliably informs us that not only is the sun unusually quiet at the moment, with its current solar minimum carrying on much longer than normal, but that it could possibly remain that way for much of the rest of the 21st century.

One of them must be wrong.

This is in complete contrast to the way things are done in .NET, where most developers put their unit tests in a separate project, preferring instead to provide a separation of concerns and keep the size of their build output down.

The problem with that is it’s a complete faff. Because your unit tests end up in a totally different part of your solution to the code they are testing, you have to navigate all over the place through the solution explorer to get between two files that you should really be working with together all the time. It’s like trying to cook a meal when your fridge freezer is in the garage, the oven is in the attic, and the kitchen sink is in the basement.

I personally find this makes me write fewer unit tests than I otherwise would. That is bad.

The other problem is that it’s much more difficult to unit test your assembly’s internal classes. You can of course use the [InternalsVisibleTo] attribute to expose them to your test assembly though, but even so it’s a little bit awkward. Additionally, since you have an extra project in your solution, it takes longer to load into Visual Studio, and longer to build. On a large solution with a lot of projects, it can get very sluggish indeed.

The argument against putting test code in the same assembly as production code is of course that you don’t want to bloat your release build. However, it’s perfectly possible to get round this by wrapping your test classes in conditional (#if) compiler directives. It is even possible — in fact, it’s surprisingly easy — to knock out the references to test framework assemblies such as Gallio, MbUnit, Moq, and so on from release builds. You can’t do it directly from the Visual Studio IDE, but if you open up your .csproj file itself in a text editor you can add a Condition attribute to the references you want to omit. For example, this code would omit the MbUnit assembly from your Release configuration, while including it in your Debug configuration (and any other configurations you may have):

<Reference
    Include="MbUnit, Version=3.1.0.0,
        Culture=neutral, PublicKeyToken=eb9cfa67ee6ab36e,
        processorArchitecture=MSIL"
    Condition="'$(Configuration)' != 'Release'" />

What do you think, readers? Are there any other good reasons why you shouldn’t do this? Personally, I can’t think of any.

It is to this particular game that the word “football” refers. Not, as they seem to think on the other side of the Atlantic, to some pretender to the name.

This one should be a no-brainer. Since the word “football” is a combination of the words “foot” and “ball,” logically it should be used to describe the game that involves the greatest amount of direct interaction between foot and ball. Running around with a vaguely haggis-shaped object under your arm just doesn’t quite cut it somehow, unless you reject the idea that words should say what they mean and mean what they say.

Perhaps in the interests of semantic integrity, we should rename American football to something like “arm haggis.” It’s more of a mouthful, and might confuse people into thinking it’s Scottish, but even so it’s a more accurate description of their particular sport than “football.”

What happened in the end? The silence has been deafening. No-one commented, no-one e-mailed, no-one phoned me up, no-one tried to persuade me that I’d been reading too much Jeff Atwood, no-one questioned my decision. This is not what I expected at all. I’d expected a string of wall posts trying to talk me out of it, people asking me what had happened, discussing among themselves what I was doing, speculation about whether someone had offended me, or whatever. Perhaps a few specially sharpened Bible verses reminding me that Jesus commands us to love one another. Isn’t quitting Facebook tantamount to social suicide? For that reason, I decided merely to deactivate my account rather than delete it outright, so that if things did go that way, I could always return. But after nearly a week, they haven’t.

The only conclusions I could draw from this were that either (a) people don’t really care about me, or (b) people don’t really care about Facebook. The more people I speak to, the more I come to the conclusion that it’s the latter rather than the former. This kind of makes sense. While the majority of my friends have Facebook accounts, a large percentage of them don’t, and of those who do, many of them seem to make very little use of it. Some of them, I just never got round to linking up with on the site, but I’m still friends with them in Real Life.

All in all, I’m far from convinced that Facebook is the “must-have” that the press make it out to be. In fact, it’s probably more of a “nice to have.” We’re told that it has five hundred million “fans” — but if up to forty percent of these “fans” are fake accounts, created by spammers and virus writers to distribute malware, and over fifty percent of the remainder are only occasional users or even dormant accounts, it doesn’t sound quite so impressive.

I’m hoping that the Diaspora project lives up to its promises. It’s a tall order, but done right, a distributed social network, where you install the software and you manage your online relationships, rather than handing them over to commercial interests, could be quite promising. By being distributed in nature, you avoid the pitfalls of a centralised social network which would put you at risk by changing the rules of the game at a whim. If they make it GPL and put it on github, it would be a guarantee against them turning nasty, since if they did, other developers would be able to come along, fork it, and release a version of their own that you could trust. Of course, in order to compete against Facebook, they need to pull out all the stops in terms of usability. After all, if it’s to be successful in that respect, they will need to pitch it first and foremost to not-computer people.

Over the past few months I’ve been getting more and more fed up with Facebook. I’ve been watching their approach to privacy and respect (or lack of it) for their users’ data with dismay, and it’s reached the point at which my distrust of the site has gone critical. Yes, they’re making noises that they’re going to simplify your privacy settings, but I am just not in the slightest bit convinced. I wouldn’t be surprised if this is a case of making the minimum concessions they can get away with to get some good PR and keep various random governments off their backs, then start pushing it up again once the dust settles.

You know these applications that you get, telling you things like what Star Wars character you are, or your Myers-Briggs type? The ones where you have to add them to your profile just to see what your friend’s answer was? They aren’t built by Facebook themselves but by third parties, who, for all I know, could have their servers in some country where data protection laws are nonexistent and the Mafia run the government. And the amount of personal data that they can get their mitts on through the Facebook developer API is downright scary.

It’s been a complete bait-and-switch. When Facebook first started, its big selling point was that it was all private: unless you were friends with someone, you couldn’t see anything on their profiles except their list of friends, and in some cases not even that. Nowadays, you can click through to almost anyone you like on Facebook and you can see everything they’ve posted and everything that everyone else has posted about them, including those embarrassing photos of them at a party several years ago. Complete strangers. I find that creepy.

I have of course locked down my account as far as I can, but I don’t even trust them with that any more—and of course, even with their new “simplified” privacy settings, there are still things that they force you to make public. That’s why, a couple of weeks ago, I deleted almost everything from my Facebook profile and left every group that I was a member of. I stopped short of unfriending everybody: that’s the last step I’ll take before actually closing my account.

For those of you who want to keep in touch with me, I will still be online, just in different places: e-mail, my blog, LinkedIn, and for the geeks among you, github and Stack Overflow. I’m also going to start using Twitter again: I closed down my Twitter account a couple of months back for different reasons that I won’t go into here, but I recently re-opened it, and I’ll probably start making a bit more use of it. I don’t have the same objections to Twitter as I do to Facebook: it may be public but it doesn’t pretend to be otherwise, and it’s nice and simple, only demanding a bare minimum amount of personal information. I’m not sure quite how much I’ll use it in the end, and I can’t guarantee that it won’t be a complete geek-out, but if you think you’ll miss me from Facebook, it’s there as an alternative.

For developers new to the concept, David Hayden has a series of video tutorials that provide what’s probably the best introduction to it that I’ve come across. He uses Microsoft’s Unity Container for most of his examples, but the concepts can easily be adapted for other libraries such as Ninject, Autofac, or Castle Windsor. He explains in some detail how to use them properly within both ASP.NET and WebForms, and demonstrates what kind of things they can achieve:

• Unity IoC and Dependency Injection Screencast
• Unity IoC and ASP.NET Screencast – Dependency Injection into Web Pages
• Unity and ASP.NET Web Pages Dependency Injection Part II with Special Guests – Autofac and Ninject
• Unity IoC and ASP.NET MVC Framework – Dependency Injection of Controllers
• Unity Nested Containers – IUnityParentContainer and CreateChildContainer
• UnityContainer and UnityConfigurationSection – Populating Unity Container via App.config or Web.config
• Unity IoC Dependency Injection and ASP.NET Model-View-Presenter