As discussed internally during our switch to Mercurial, we should have
a stated policy on how to write log messages when committing our work
to the repositories.
I've always found the Subversion dev team's guidelines on log messages
to be a very useful example. I would like to submit to the rest of
the devs the following as a template for what our policy should be
Mercurial log listings emphasize the first log line of every changeset
as a summary of the changes, as does the abovementioned guideline.
I'd say this is the single most important thing to get right. You
will not need to look far back in the NAV changelog to see some really
bad examples of log messages, which were common among some of the
earlier developers (The guilty shall remain anonymous. Until you
actually inspect the logs).
I'd like comments from current devs on the abovementioned guidelines.
Should we blatantly copy them and replace all mention of Subversion
with NAV, or should we make some appropriate changes?
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).
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
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