Why did we develop EasyMercurial?¶
The SoundSoftware project works with research students in the UK audio and music research field. Like much research work, this often involves developing software and collaboratively working on papers and publications.
Version control is very helpful for these activities, but our experience suggests that many researchers in this field either are unaware of what version control can do, or consider it too fiddly and technical to use. Many researchers working in audio and music have no significant prior experience with typical software development tools.
We have found that many of the existing user interfaces for version control are quite hard to explain to users with no existing mental model for version control.
For example, user interfaces for distributed systems typically show commits in a linear sequence even when they actually occur "simultaneously". This linear presentation scales more easily for large projects, but a graph that is representative of the real shape of the history is easier to explain. Many user interfaces permit simple user oversights (such as forgetting to "add" a new file) to happen too readily, or make common workflow sequences (such as update-merge-commit or pull-merge-push) inaccessible to exploratory use.
The Software Carpentry / SoundSoftware.ac.uk Autumn School 2010 included an introduction to version control, which was very well received. However, the Subversion user interface used in the school proved rather complex for many first-time users and we found few easily understood user interfaces for distributed version control systems. Those that do exist tend to be specific to a single platform, unlike our audience.
The simplest user interface approach we found was that of HgExplorer by Jari Korhonen, which made a refreshing change from the complex layouts users are immediately faced with in most version control tools. We decided to work from this (with Jari's assent) in order to make the workflow more explicit and to expose the repository history in a graphical layout, using ongoing testing from research users in the hope that we could produce an application well suited to our purposes.