I'm using mercurial for personal projects and thought I'd share the approach I use with you so you can teach me to improve it.

(If you don't have mercurial, download it and install it now, so you can follow along)

(This isn't a "joke" post by the way. Sometimes my sarcasm runs so deep that I need to stop and reassure people when I'm not being sarcastic. In particular, I need to reassure myself ;-) )

Say I'm creating an open source project, such as fuv. I create the project online, then clone it locally:

c:\projects>md fuv
c:\projects>cd fuv
c:\projects\fuv>hg clone https://hg01.codeplex.com/fuv

(If I'm just creating it locally, like if it's closed-source, then I begin instead with 'hg init.')

The very first thing I add is a .hgignore file. This is the file where you tell mercurial *not* to check in all of those pesky user-specific files that a visual studio project generates, and to avoid versioning the bin and obj folders etc.

I've stolen the .hgignore file from the Funnel Web project because 1) the guys working on that project are much more thorough and intelligent than me, and 2) it was the first .hgignore file I found lying around on my hard drive.

The .hgignore goes in the same folder as the .hg folder. It doesn't go *in* the .hg folder (you don't normally have to go in there at all). It goes in the parent of the .hg folder.

Now it's time to write the code. You could either copy code in from elsewhere (if you had already started it) or if starting from scratch, create a new solution in the folder you've just created.

Here's the bit that I think is clever/stupid. I put a 'post-build' action on the project, so that everytime I build succesfully I check in the work in progress.

It's as simple as adding this to the post build step:

hg addremove
hg commit

This is clever because it means that every tiny change you make is tracked. And it's stupid for the same reason. The main reason reason it's stupid is that it means everytime something has changed you are asked to enter a commit note in a notepad.

It's quite annoying at first. But soon you get into the spirit of it. You realise that it is making you act in a more mindful manner. You are concentrating on every build, more aware of what you are doing, and better focused on your tasks.

Still, that bit could be improved, and it definitely wouldn't be to everyone's taste.

When you've completed a feature you push your work to the server using hg push, like this:

hg push

You have to enter a username and password at that point. Or, if you're pushing often you can store the username/password in mercurial's configuration.

There's a lot of different places and ways you can store this info. I'm going to describe one in particular, but I'm not saying it's the best one. Opinions or improvements welcome.

Remember I said earlier that you don't need to go into .hg folder.... well... go in there. There's a file called 'hgrc.' Editing it using something better than notepad (as it seems to have unix-style line-endings rather than windows-style line-endings (aka '\n' not '\r\n', aka 'Lf' not 'CrLf' aka 'char 10' not 'char13 char10').

Add three lines to it, to tell it the user name and passowrd, and which site they refer to:

[auth]
codeplex.prefix = https://hg01.codeplex.com/fuv
codeplex.username = secretGeek
codeplex.password = joshua

(Joshua is not my real password by the way. And the word before the "." can be whatever word you want as long as it's consistent across all three lines. It's just for grouping purposes.)

Here's the stackoverflow question on mercurial passwords that I got this from.

Automate your pushes!

Once you've got your username/password in place, you can make the push a post build action too!

To make it so that a push only occurs on a 'release' build, try this:

if /I "$(ConfigurationName)" == "Release" hg push

After that you've got an automated, integrated approach to version control even for the most insignificant of little projects.

Getting it setup and in place takes just a minute or two for a new project.

Some of the tweaks I'd like to make to this system are:

1. use some kind of a custom script to generate a proposed commit message. Perhaps it could look in your todo list (such as nextaction) to grab the item you are currently working on.

2. somehow 'flattening' the local commits when pushing, so that all of the in-between personal revisions are squished out of the way.

Also, I've been thinking about using mercurial (with 'auto commit' as described above) for managing a todo.txt file. Every time you save it commits, and a script looks at the diffs to see what tasks were deleted, marked as done, edited, added, etc. While it's an intriguing idea, I think it would need you to be very disciplined and somewhat restricted in the way you use the todo list.

(nexaction, by the way, lets you run custom shell commands when you complete a task. So you could use this to commit the file every time you complete a task. It's a feature I've never discussed with humans, out loud.)