(Quick aside: does anyone know how to link to past posts in the journal? The "link" button nicely gives a perma-link to an old post, but it contains "", which gets swallowed when I put it into a journal entry.)
OK, at this point, I've gotten Mercurial installed, and from doing the Tutorial I know the basic commands, or at least how to find the documentation. Next, I need to figure out how to store my code. Or, in source control speak, what repositories should I create?
The Mercurial documents suggest making a base repository, and then cloning that repository for each "feature" that I want to work on. Then, merge back these changes into the base repository as the features are completed. Perhaps this is sound advice for distributed teams, but for starting out, I recommend you just make a single repository for your source code. You'll get all of the source control/revision/history management, without having to worry about keeping multiple repositories sync'd, built, and all that.
Now, when using source control, I want to have all of my source code (.cpp files, etc) in source control. But I don't want to checkin any of my built stuff (.obj, .exe, etc). Afterall, I can rebuild that stuff anytime. And keeping track of every version of every object file is going to use up storage space in a hurry!
Further, I want _all_ of my source code to be in source control. If I add a new file, I want that file in Mercurial as well. Unfortunately, Mercurial doesn't automatically add files to source control if I put them in my repository directory (to be fair, neither does any other source control system I've used). So, to use Mercurial effectively, I recommend frequently running hg status. hg status lists non-checked in files in the repository; A for a file that has been added but not checked in, M for a file that has been changed and not checked in, and ? for a file that isn't under source control at all. My strategy is to type hg status often, and eliminate all of the ? files, either by deleting junk or using hg add to add the files to source control.
Unfortunately Visual Studio doesn't play great with this strategy; it wants to put all the generated files in the same directory as the source code. I can think of three reasonable solutions to this problem:
- Figure out how to make Visual Studio put generated files in another, parallel directory. Perhaps this is really easy, but I didn't bother to even try.
- Switch over to using makefiles; Visual Studio ships with nmake.exe which is a perfectly reasonable command-line building tool, and it should be pretty easy to configure this to put output files where-ever you want. In fact, I would strongly recommend this approach for multi-developer projects, because then you can run an automated nightly build easily. But I didn't bother because I am a one-man band.
- Put the Visual Studio project files outside of source control, but point the project at source code in source control. This was my choice because it is (more or less) the easiest.
A drawback of my strategy is that my project files aren't under source control. Luckily I keep my projects pretty simple, and reconstructing one would only take a few minutes. Still, if I ever really expected to do this, I would find some way to get them into source control.
The last recommendation I have is to get in the habit of checking in (hg commit) early and often. Every tiny little change you make, once it is (more or less) working, check it in. I generally check in changes about once a day. Maybe that seems like a lot, but Mercurial stores changes with diffs, so there isn't much storage cost, and I _love_ having all that history to look at. Backing out changes, or comparing new code to old code, to every building version of the code, is really nice.
So, in a nutshell, my recommendations for using Mercurial for a small dev project:
- One repository for all of your source code.
- Figure out some way to put your generated files (objects, libraries, executables) in some different path outside the repository.
- hg status often to be sure you have all of your code under source control.
- hg commit every change, from the major to the one-line bugfix.
OK, that's all about Mercurial. I'll find something else to blog about in the next edition of RPG Anvil.