Mercurialhttp://norman.walsh.name/2007/07/19/mercurial10692007-07-19T09:01:22-04:00$Date$NormanWalsh2007Norman WalshThe version control system, not my personality.The moment I learned that such a thing as a
“version control system” existed,
I was hooked. Over the years, I've used a few. I started with
RCS then moved to
CVS. I used
ClearCase for a while.
(At the time, I was working remotely over dialup. Let's just say that ClearCase was
not optimized for that scenario and leave it at that.) I've done a
Perforce checkout or two, for something
TeX-related as I recall, though I can't really claim
to have used it.A few years ago, I switched to
Subversion.
Atomic commits. The ability to rename files and directories. Atomic commits.
Versioned metadata. Atomic commits. I've been very happy with it. Especially
the ability to make atomic commits.A version control system is absolutely imperative if you're
working collaboratively. There's really no other practical way to
manage multiple developers updating the same code base.But I use a version control system for
everything that I do. I recommend that you do the
same. I manage papers and projects that only I touch with Subversion.
Heck, I have my whole home directory checked in.Using version control for my own stuff has two obvious benefits.
First, it protects me from the single most likely to fail component of
my work environment: me. If some line of editing turns out to be a complete
dead-end, you can just throw it away and check out the “last good” version.
Second, it provides automatic backups. Well, sorta.You see, I work disconnected from the net fairly often (think
airplanes, vacations, etc.) and I really don't like to be unable to
check stuff in. It just increases the window of opportunity for me to
screw up and if that window gets big enough, I will.In order to make it possible to work without an internet
connection, I keep a lot of stuff checked into repositories on my
local disk. So, yeah, if I rm * (instead of
rm *~) in some directory, I can recover. But if the
disk fails or the laptop is stolen, I'm hosed. Oh, I have proper
backups, but they could be a few weeks or a month old. You want to
lose a month's work? Neither do I.This is where distributed revision control systems come in. Instead of
a central repository that you have to be connected to, they work peer-to-peer.
One practical consequence of this is that you can do check-ins, commits, or any
other action while you're disconnected. The next time you are connected, you can
“push” these changes to your peers.I've been interested in trying one of these systems for a while
(there are several). Since it looks like
OpenJDK will use
Mercurial, I figured
that would be a good place to start.It was fairly straightforward to setup Mercurial on my web host
and create some repositories. With some trepidation and a few days
hacking, I've converted the source for
,
, and even
to Mercurial.So far, it's been pretty painless. There are
Subversion-to-Mercurial conversion tools, so I didn't loose any of my
history. I have a few scripts that extract information from the commit
logs; those had to be changed to work with Mercurial. I rely on
keyword substitution (the $Date$ keyword provides the last-updated
date), so I had to get and install the right
Mercurial extension for
that. It turns out that Ubuntu has not-quite-the-most-recent Mercurial
release, so it took a couple of email exchanges with the author of the
extension to get it working.Then I just had to wait for my laptop to rebuild
everything. Seems to have succeeded overnight. If
you see something that looks screwed up, please do tell me.(Before you hit the “add comment” link, yes I know, I could have
accomplished the same goal, probably much more easily, with svnsync.
But I wouldn't have learned anything practical about distributed
version control that way, would I?)