WhyEasyHg » History » Version 7
Version 6 (Chris Cannam, 2011-03-14 05:14 PM) → Version 7/11 (Chris Cannam, 2011-03-14 05:15 PM)
h1. Why did we develop EasyMercurial?
The "SoundSoftware project":http://soundsoftware.ac.uk/ 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":http://soundsoftware.ac.uk/autumnschool2010review 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 approach we found was that of "HgExplorer":http://code.google.com/p/hgexplorer/ by Jari Korhonen, and we decided to take this (with Jari's assent) and develop it with ongoing testing from research users in the hope that we could produce an application suited to our purposes.
The "SoundSoftware project":http://soundsoftware.ac.uk/ 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":http://soundsoftware.ac.uk/autumnschool2010review 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 approach we found was that of "HgExplorer":http://code.google.com/p/hgexplorer/ by Jari Korhonen, and we decided to take this (with Jari's assent) and develop it with ongoing testing from research users in the hope that we could produce an application suited to our purposes.