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...
Submitted without comment: http://www.whygitisbetterthanx.com/.
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?
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.
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.
This is a test...