Mercurial: a field report
May 31st, 2006 by Samuel TardieuAs a member of the Areabot association, I participated to the 2006 French robotics competition last week. We had to develop specific software for our robot, driven by two Shix boards containing each one a SH7750R processor at 240MHz running Linux and a Stratix EP1S25 FPGA.
We decided to use Mercurial from the beginning for our main repository. We set up a central repository where the eight active developers could push their changes using a SSH key. Most of the users could not log into the machine as it was shared with industrial projects; they only had access to Mercurial under a shared uid.
Six users were new to Mercurial. Most of them never had used any distributed revision control system before, and some of them had never even used CVS. The basic operations (clone, pull, update and push) were easily learnt, but the first merges seemed to look like black magic to them. After a quick explanation, they were able to handle conflicts and avoid them whenever possible.
When we arrived at the contest site, we lost the connection to the central repository as no Internet access was possible there. However, most developers had a checked out copy of the repository on their laptops. We set up a small LAN and continued to write code on our laptops. Being able to serve our changes using Mercurial’s integrated server was a real pleasure. We only had to ensure that each one of us had a hg serve running, and we continuously pulled changes from one repository to another.
In one occasion, we were unable to setup a LAN between the two laptops we were using and needed to transfer the latest changes from one of them to the other. Rather than copying the raw files to an USB key, we created a Mercurial repository on it, pushed to the repository from the up-to-date laptop and then pulled from it from the other laptop. This way, no files were ever exchanged outside the revision control system and this didn’t take any extra time to do so.
So to make it short: Mercurial was a real help for our development, both in connected (central repository) and disconnected (peer-to-peer) modes. Having a full access to the whole history was very valuable.
Some figures:
- Number of active developers: 8
- Time span: two months
- Lines of code written for the competition: 30617 (3503 lines of C, mostly Linux device drivers, 12542 lines of Ada, 357 lines of Makefile, 14215 of Verilog for the FPGA, some of them being shared with other projects using the same board)
- Number of commits: 700 (including 89 made while on the contest site)
May 31st, 2006 at 13:12
How did you select what actually ended up on board, with so many concurrently active branches being maintained?
May 31st, 2006 at 13:18
Those branches didn’t diverge. When someone had some code ready, it was pulled by the person doing the tests on the robot at this time and tested right away.
We had a policy on the central server not to push anything unless it compiled so that someone doesn’t end up with a non-buildable version because of someone else. This was not enforced with technological solutions but could have been. In peer-to-peer mode, we were constantly working together (working in 21 hours shifts with about 3 hours of sleep per night while on-site) and when something was ready the developer asked the current tester (if different) to pull from his repository.
May 31st, 2006 at 14:08
OK, so actually the development process was completely serialized…
May 31st, 2006 at 14:10
Not the development process, only the testing process. We only had one physical robot, so we couldn’t test two branches at a time. It was easier to reintegrate changes before testing.
At some occasions however, two developers changed different things and tested one after the other (we had a network access to the robot) as each test took a few seconds only. In this case, the changes have been reintegrated together. But this was not our common way of working.
June 1st, 2006 at 0:23
Hi Sam, should I undestand that DARCS is no more the distributed SCM of choice for you?
June 1st, 2006 at 0:27
I just love Darcs, but it is painfully slow when working on large repositories (for the contest, I worked on the GCC+GNAT tree and the Linux kernel tree and Darcs would have taken ages to perform minor operations). Mercurial is blazingly fast.
June 1st, 2006 at 8:43
This is what I am experiencing whit DARCS.
I was really pleased when trying it on my Linux box on a small personnal project. But when using it at work on a 4 guys project… some of the pull just never complete! I wondered if it was specific to the Solaris version, you answered.
I’ll give Mercurial a try.