Staying on top of Changes with Mercurial

If there’s one constant in software development, it’s change. Little changes here and there, and the occasional big change happen all the time.

Web development is the same, and arguably even more so. Freed from the need to package everything up and ship it in a numbered release, it’s all to easy to fix a single small bug and immediately make it live on the site. Or change a single word on one page, and make that live.

If you have more than one person working on a project (web or otherwise), keeping everyone’s changes in sync can be a chore. Back in the day when Jared and I were working on Redux together it was a simple matter for one of us to “claim” a chunk of the source code for an hour (or a day), telling the other to keep their hands off it.

Nowadays there is an entire genre of Source Code Management programs that keep track of everyone’s changes with a minimum of fuss. In addition they document changes, keep track of different revisions, know what files were changed when and by who (and why). They eliminate the possibility of one person stepping on another’s code (and wiping out their changes), and should a change go completely astray, they even let you revert to any earlier (working) version.

After looking at a few different SCM programs, I settled on Mercurial, which seemed the best fit for my working style. It’s lightweight, and installs easily on Mac OSX as well as the various Unix servers that host my web sites. You control Mercurial from the command line, using the new hg command it installs (from the chemical symbol for mercury: Hg).

After installing Mercurial, the first step was to pick one of my websites and tell Mercurial which files I want to keep track of for the site. I then made a snapshot of those files, or as Mercurial refers to it, a “changeset”. It asked me to include a brief comment with the changeset to describe it; for the first changeset a comment like “added key site files” worked just fine.

Now I make changes as usual, and Mercurial keeps track of what changed. I frequently commit a set of changes to a new changeset, along with a brief note describing the change. At any point if I don’t remember what I’ve changed a simple hg diff command will tell me not only which files changed, but which lines in those files changed (both old and current versions).

What’s very cool is that I can keep a local copy of the website on my MacBook, make changes locally and testing them, and when I’m satisfied that the changes are ready to go live I can send those changes to the website with a simple command: hg push.

Once the changes have been pushed to the site, I can make them live at my leisure; a simple hg update command instantly makes the changes live. No more fussing with uploading changes with ftp, messing with renaming files or worrying about copying files to the wrong directory.

Mercurial is easy to install, easy to learn, and easy to use. It makes it easy to keep track of changes, and to migrate those changes to different developers (or different locations, like live web sites). I’ve only scratched the surface of what it can do, but even after just a few days it’s already made my life easier.

5 thoughts on “Staying on top of Changes with Mercurial”

  1. Welcome to the fun side of the world 🙂

    The “offline-mode” of being able to edit on your laptop, keep history of the changes andpush not only the files but the *full* history of the changes too, is what gets most people interested in Mercurial at first.

    I really enjoyed reading this post, so I am looking forward to more nicely written, cool posts about how you work wth Mercurial. Especially if you also start collaborating with others through repository clones, and pull/push changes merrily around.

    I am using Mercurial too, but not for web-visible content, so keep them posts coming 😉

  2. I’ve got one question about Mercurial that is kicking my butt. If we host one repository that holds the “real” site and then we all have repositories that we use for doing development. how do we reconcile changes when more than one of us has changed a single file? I’m reading more about this now but it seems a little complicated.

    1. That’s pretty easy. Basically you have a production server for the live site, and a staging server that you use for testing and development. Each developer also has his or her own development server, most likely running on their computer. So you make changes and test them out on your machine, and when you’re ready to share your changes you first pull down the latest changes from the staging server, then push your changes up to the staging server.

      If there are any conflicts you resolve them on your machine, so what gets pushed to the staging server is conflict-free. For the most part mercurial is smart about merging files that multiple people have changed, but if it runs into a problem where two people change the same line of code it will ask for your help in resolving the conflict.

      Each developer works this way, first grabbing the latest and greatest from the staging server, then pushing their changes back up. Of course it still helps to coordinate with each other to minimize conflicts (two people working on the same web page simultaneously is just a bad idea).

      When things are running smoothly on the staging server, when you’re ready to roll it out to production it’s simply a matter of pushing the changes from the staging server up to the production server. Other work flows are possible (for example pushing changes from a developer server to production, or from the production server pulling down changes from the staging server). It all depends on what works best for your team. Good luck!

Comments are closed.