The Limbo song asks, “How low can you go?” Limbo is a strategy for scaling collaboration on software projects by reducing the size of changes to be merged and increasing the velocity and reach of propagation of changes.
The original Limbo paper suggests that changes should be transformations of the abstract syntax tree of the program. However, until the inevitable day when all changes are tree transformations, it is useful to experiment with textual diffs, just to see what Limbo will feel like, what incentives it creates.
Yesterday, our Code Camp at Iterate in Oslo spent the day coding in the cheapest possible implementation of Limbo. This paper describes our implementation of and experience of Limbo, in enough detail that you can try it yourself.
(Ab)using Git
Rather than have tree transformations zipping around modifying the program, we chose to use Git. Both pairs cloned the same remote repository. Then we ran the following shell script:
while(true);
do
git pull --rebase;
git push;
done;
How would we make sure we didn’t break each others’ code? We wouldn’t propagate changes unless all the tests pass. After every change, we ran this script:
test && git commit -am working
The “test” script builds the system, runs the tests, and only returns 0 if all the tests pass. (We actually reverted if the tests failed, but that is a tale for a different article.)
Experience
Few conflicts. One goal of propagating tree transformations is to reduce merge conflicts. Even with two pairs working on a small program, though, there weren’t many merge conflicts.
Small commits. The incentives of working Limbo-style encouraged many small commits. Commit size formed a log-normal distribution.
Fun. In spite of the pressure to get smaller diffs in sooner, working Limbo-style was fun and absorbing. The challenge of finding a way to make a (relatively) large change in small, safe steps was interesting and seldom frustrating.
Thanks to Iterate for sponsoring the work and to Lars Barlindhaug, Oddmund Strømme, and Ole Johannessen for working.
