UCL Bootcamp: Version Control Wrap-Up

This post originally appeared on the Software Carpentry website.

For the bootcamp at UCL, we tried using Mercurial (with EasyMercurial) instead of Subversion in the version control segment.

You can see the plan for the segment on this EasyMercurial project page. Briefly, we opened with a few plain slides about the purpose of version control, followed by a hands-on example in three parts (working by yourself, working by yourself with an online remote repository, and working with others). We started at the beginning and got as far as "hg bisect", but did not cover branching.

I was presenting the segment, so I'm not well placed to judge how effective it was as a learning experience. But I did make some notes.

Command line or GUI?

I started with the EasyMercurial GUI, made some (but in hindsight probably not enough) attempt to show how GUI operations corresponded to command-line operations, and dropped back to the command line for more esoteric ideas at the end (such as bisect).

However, more of the attendees were familiar with the command line than we had expected, so it might have been simpler to use that for the basics. Getting from nowhere to "...and now we're using version control! see how easy that was" is a shorter process at the command line. Using a GUI introduces distracting complications, such as the need to switch windows—aggravated in this case by my finding I wasn't practised enough at doing the necessary switching cleanly when using projector resolutions and huge fonts.

On the other hand, EasyMercurial has a better view of the history and clearer merging, and I certainly wouldn't want to introduce divergent simultaneous commits and merge conflict resolution without those. (In my daily work I also use the GUI to manage these activities, even though I'm instinctively a command-line user.)

It seems counter-intuitive to say that the command line is better for basic stuff and the GUI better for advanced stuff, but perhaps that is the way it is. It would be interesting to have more feedback from others who were present.

Peer-to-Peer or Master Repository?

A common requirement is to share code between "my computer" and "the lab compute server" (implied for example in the "frequently asked question" at the end of the Software Carpentry version control lecture).

We approached this by using a master repository stored on an external server, in this case Bitbucket. But since we have a distributed version-control system, we could have taken a peer-to-peer approach, pushing and pulling between peer repositories on the two machines directly. We could have done this for sharing changes between paired neighbours in the bootcamp, as well.

Using a master repository has advantages such as redundancy, availability, and backups. It's probably better practice in a real lab, and it's also easier to use a known remote server in a setting like this where everyone has one machine in front of them with a dynamic IP address using an unknown network topology. On the other hand, there are situations in which it's useful to know that a peer-to-peer arrangement is possible, and I do wonder whether we should have demonstrated it in some way.

One We Made Earlier?

We didn't have any pre-prepared working material in the segment, just a few introductory slides followed by building a repository from scratch (with recipes in it). One suggestion was that we could provide a canned repository for people to start from to get them more quickly into "working together" mode.

My fear is that this would be to miss one of the biggest strengths of a distributed version control system: how simple it is to start using version control on your own project, without technical support from anyone, and then to push a server with all your history intact whenever you feel like it.

Delivery and Technical Bits

The biggest practical problem we had was that the room was fairly big with no microphone, and I simply don't speak clearly and loudly enough to be heard by everyone at the back. I need to work on this!

There were a few technical problems with software installation, some of which we should be able to solve before next time around (e.g. issues with the EasyMercurial package on some versions of Ubuntu or with installing from source on Fedora). There weren't all that many of these problems, but it doesn't take very many to bog down a workshop. On the upside, we didn't have any network problems during this segment (a common cause of trouble).

I started out feeling a bit rushed, and although I had a plan and I largely followed it, I did forget to include a couple of planned excursions aimed at explaining more about which system we were going to learn and why, as well as some material about how often to commit, what material to include in a project under version control and so on. Generally I failed to provide as much context as I had intended to. However, the technical material did appear to be about the right amount for the time (and attention) available.

One thing we did that proved a bit tricky to set up and awkward to do, but that I think seemed worthwhile and that I would like to try again, was to use two projectors and thus show "both sides" of a collaborative working process with two people making edits live at the same time. Again I'd like to hear what others think.

Onwards

I'll be running the version control segment at the Newcastle bootcamp as well, where I'll be trying to improve on some of the things that didn't go so well at UCL. This does mean it'd be great to have any more feedback sooner rather than later!

My thanks to Ben Waugh for the organisation at UCL, Chris Harte for presentation suggestions beforehand, and Luis Figueira for running the second laptop during the session.