I’ve used the cvs and svn version control systems for both work-related and personal projects. For personal work, I used svn in particular more as a backup program, with the added benefit of the version control. Keeping my repository on a thumb drive made it easy to perform the backups when traveling, but perhaps because of sloppiness in removing the thumb drive without clicking the right icons first, my repository got corrupted too often, so I gave up.

I decided to try again with Mercurial and was shocked at how quickly I was able to learn it and get it to do everything I wanted—about an hour. This blog posting convinced me to try it before git, which sounds fascinating but a bit more complicated. By keeping my repository on the local drive and using the clone feature to keep backup copies of the repository elsewhere, I can redo a backup if a thumb drive version gets messed up.

The Mercurial Quick Start lives up to its name, and I kept some notes as I went along to provide my own Mercurial quick reference:

hg init Turn current directory into a project. hg add``` Add files in current directory to repository. hg ci -m “comment about this commit” Commit recent changes to repository.hg clone . e:\otherCopy Create a clone of the current directory's repository somewhere else.hg push e:\otherCopy Send recent changes in this directory's repository to a clone repository (that is, back up the changes here to there).update (entered from within e:\\otherCopy directory) Make clone directory's contents reflect recent changes to clone repository.hg log test1.txt List comments (see -m above) for each of test1.txt file's changes.hg revert -r 1 test1.txt Revert file test1.txt to revision 1. (You can then "revert" it to later versions.hg cat -r 2 test1.txt Look at version 2 of test1.txt.hg locate foo` List files in repository with “foo” in their names.

One other note: an .hgignore file tells hg files which to ignore, and putting separate .htignore files in subdirectories of your main project directory works fine.

I once had grand ideas about hooking up a version control system that can assign arbitrary metadata with an RDF triplestore to form the basis of some sort of CMS demo. Mercurial isn’t much help here, but when I prioritize the tasks “back up my stuff” and “build a demo CMS around a version control system” the former is clearly much more important. Maybe someday…

5 Comments

By Norman Walsh on October 26, 2009 7:00 PM

Submitted without comment: http://www.whygitisbetterthanx.com/.\

By Bob on October 26, 2009 7:46 PM

In my entry above I wrote that I “was shocked at how quickly I was able to learn it and get it to do everything I wanted—about an hour.” I exaggerated a bit; it was closer to an hour and half. On September 24th at about 11:30 AM GMT I told Norm “I’m going to try Mercurial now”. At about 1 PM I told him “I tried it and really liked it”. And now he tells my about whygitisbetterthanx?\

By Dirkjan Ochtman on October 27, 2009 4:40 AM

Don’t believe the git hype…

BTW, you name ‘.htignore’ here, where I believe you mean ‘.hgignore’, and actually putting those in subdirectories of a repo doesn’t work (not sure why you have the impression that it does).

Actually Mercurial’s filelog structure has a neat metadata mechanism built-in where you could store versioned metadata per file, and the changelog (where the changeset history graph is stored) can also hold arbitrary bits of metadata, so you might be able to leverage those capabilities to do some interesting things.

By Bob on October 27, 2009 9:53 AM

Thanks Dirkjan. I fixed the .hgignore filename and then struck out that sentence. I guess my opinion was based on a quick test where I wasn’t paying enough attention.

By Bob on November 11, 2009 8:11 PM

This is a test…