CVS FAQ
Why do you use CVS?
Here’s a question we get asked quite a bit: why don’t you guys use SVN/git/Mercurial/Perforce, etc, etc?
We did consider SVN when we first set up the website. You’ll see that we have a SVN repository in which we keep the applications that run the website itself. However RISC OS has used CVS since the mid 1990s and we’ve decided to stick with it for at least these reasons:
- We have a number of administrative scripts for sanity-checking source submissions and managing builds and source releases (including the autobuild system used by Pace which we’d probably use as the basis of our own). You can find these in castle/Admin/bin, and they’re all wrappers around CVS, and so they would need rewriting for any other system.
- Tagging and branching of the sources are always done on a per-component basis (where a component usually corresponds to a module, application or library). Development branches are always per-component, but there are other branches (HAL, Ursula, Spinner and so on) which are common to many (but not all) components. And again in some but not all of those, those branches have been merged to the trunk, but in other cases they are still “live”. I don’t think most version control systems permit this level of flexibility – you’d need a repository per component. But the wider directory structure outside the components is important for the build system too.
- A lot of the justification for code changes (and even in some cases documentation of changes) is only held in the revision logs, so we want to preserve them. There are automated tools for converting CVS repositories to other systems, but they fail on this repository, probably because of its complicated branching history.
- There is still more source to be released. While everything is CVS, we can simply patch bits of the old Castle/Pace/Acorn repository into the public repository and use tools to search for licensing problems, profanities and so on, and automate the insertion of licence headers. We lose that if we change to a different system.
- If we were to change revision control system, even SVN is a bit old hat these days. Something like Mercurial might be a better choice (although there’s no RISC OS client and it still has the problem of no per-component branching).
The biggest drawback that CVS has in our case is the inefficiency – both in terms of bandwidth usage and in speed – of updating remote working directories. This hasn’t been a big issue until recently because there weren’t many developers, but this is now changing. One solution would be to use a program called CVSup, which is a bit like rsync but optimised for mirroring CVS repositories, so that each developer can maintain a local read-only mirror of the repository. However we’ve held off this up to now, mainly because it’s a royal pain to install at the server end.
