As stated in this year's development project, we will migrate NAV's version control system to a distributed version control system.
After playing around with Bazaar-NG (bzr) and Mercurial (hg) for a while, we've finally chosen Mercurial for the job. Please see http://www.selenic.com/mercurial/ for more information on Mercurial.
Mind you, this choice is very much based on gut feeling and prior SCM usage patterns. There is little that distinguishes bzr and hg in terms of functionality, which has made testing a typical NAV release cycle with each tool an important part of the decision.
Where and how =============
Although Mercurial supports named branches, I've elected to convert each Subversion branch into a separate Mercurial repository. These repositories can be found at the following URL:
The Subversion trunk can be found as the repository named "default". Each repository actually uses one named branch each, which will make it easier to identify where changes came from when merges occur. This won't be a hard requirement though, but it is good to know when cloning and working with one of the branch repositories.
Push access to the repositories will be granted to the developers currently employed by UNINETT (please come by my office to get a username/password). Other developers are encouraged to publish their own repositories, and ask us to pull from these when changes are ready to be merged with the official repositories (Or send us your Mercurial bundles or regular patch files).
Although the new distributed model enables each developer to work "offline" much of the time, I strongly urge you to regularly push your changes to a an offical feature branch (if you have one, that is).
Quirks ======
There are some quirks in the conversion, mostly due to the different world view of svn and hg.
First off, we've lost some of our tags, more specifically, all the 3.0.0_alpha* tags. These weren't very important anyway, so they will probably not be missed by anyone. These tags were not understood by the conversion tool because of the way they were created (in the old days, when we hadn't familiarized ourselves properly with Subversion yet).
The second quirk is a similar problem. Each release of NAV contains the file named VERSION, which contains the NAV version number. For each release, I checked out a working copy of the current release branch (e.g. 3.3.x), changed the contents of VERSION (e.g. to 3.3.1) and copied my working copy to the subversion tags directory. The resulting revision is a copy of branches/3.3.x to tags/3.3.1, with a small change to the VERSION file. Since tags don't work like that at all in the modern distributed systems, the conversion tool couldn't pick up the change that happened to the VERSION file as it was tagged. The end result is that the contents of the VERSION file will not be correct in the version tags that are present in the Mercurial repositories. The only way this could have been mapped to a DVCS was if each release version was made into a branch of its own.
I could have elected to set tags on all changesets to map them to the corresponding Subversion revision number; this would have made it easier to identify changesets referred to by changeset comments, old SourceForge bug reports and mailing list messages. On the other hand, I felt this would clutter opp the tag listings for the repositories, and make tags less useful (>4000 tags!)
I do, however, have a "shamap" file from the conversion tool, which maps each Subversion revision number to a Mercurial changeset SHA id. I would like some suggestions on what to do with this file, since it could be useful. Should I publish it on the web, or commit it to the default repository?