April 2008 - Nav-dev - lister.unit.no

Commit log policy
by Morten Brekkevold 10 Apr '08

10 Apr '08

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 like: http://subversion.tigris.org/hacking.html#log-messages 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? -- mvh Morten Brekkevold UNINETT

1 0

pst fryser
by Knut-Helge Vindheim 08 Apr '08

08 Apr '08

Periodevis så går det veldig tregt, det ser ut som om pst fryser og at data i fra databsen går veldig tregt. Mvh -- Knut-Helge Vindheim NTNU, IT-Avdelingen / Nett Tlf 73590011

2 1

innsamling av dhcp-leases i cricket på pst ser ut til å ha stoppet.
by Knut-Helge Vindheim 07 Apr '08

07 Apr '08

som subjektet seier+ at jeg ikke ser vlan som blant annet 191. Mvh -- Knut-Helge Vindheim NTNU, IT-Avdelingen / Nett Tlf 73590011

1 0

Version control migration
by Morten Brekkevold 03 Apr '08

03 Apr '08

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: http://metanav.uninett.no/hg/ 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? -- mvh Morten Brekkevold UNINETT

1 0