NetBSD migration path to Mercurial

This page describes what's involved in migrating NetBSD from CVS to Mercurial.

What Mercurial is

Mercurial is an open-source version control system. It is a distributed version control system based on the commit hashcode model shared with git and other DVCSes. It is fast and powerful and has long emphasized a certain polish of production.

Why Mercurial

Mercurial is a modern VCS; it is maintained; it is capable of handling the NetBSD repositories; and it is cleanly designed, simple, and easy to use. The first three of these properties are necessary requirements for NetBSD to migrate (I don't think any of them are particularly controversial); the last sets it apart from git, which is the other immediately available alternative. (The third option, writing our own, is not currently realistic.)

One could write a lot of gung-ho IT IS REALLY GR8!!!11!! boosterism here too, of course, but I'll leave that for someone else.

Migration

There are two categories of issues related to migrating a project the size of NetBSD: first, what the project and the world around the project will look like after the migration is done, and second, what things need to be done to get there. The purpose of this page is to tackle the first: what things in the project will be different and what they'll be like. This includes not just user-facing things like commit procedures but also backend considerations and administration.

There's a second page with a list of work that needs to be done.

Issues

Technical concerns (demands on the system's operational model)

atomic commits / changesets
rename support
authenticating commits
numbered versions
branch handling
tag handling
partial checkouts (partial trees, partial history)
blacklist extension (which is a legal requirement)
being able to migrate away in the future
...

Conversion of CVS repository phenomena

vendor branches
conversion of repo-copies and similar CVS horrors
adding rename metadata to already-done moves
pkgsrc not-really-vendor imports
developer usernames vs. email addresses in log messages and commit metadata
non-ascii text in log messages
version references in log messages
retaining CVS file version numbers as metadata
restoring the pre-USL-settlement history and/or including the CSRG history

Implementation concerns (demands on the system as it exists)

general performance
importing into base, or not
storage requirements vs. small systems
memory requirements vs. small systems
possible workarounds for small systems
...

Community deployment issues

what becomes of anoncvs
making use of version numbers in mailing lists / security advisories
patches/contributions/commits from non-developers
collaborating with non-developers

Developer deployment issues

commit procedures
development branch procedures
vendor branch procedures
private branch procedures
collaboration without pushing to the master repositories
rebasing vs. merging
how to refer to other commits in log messages

Many of these issues are already documented in the existing workflows writeup.

Releng deployment issues

changes to the way pullups are filed
adjusting processing scripts for new source-changes format
release commit procedures
release branch procedures
dealing with accidental commits to release branches
preventing accidental merges into release branches
extracting formal release tarballs
shipping source tarballs
...

Backend/admins deployment issues

how commits get pushed to the master tree (log who's pushing what, e.g. using the pushlog extension from mozilla)
log_accum / source-changes mails
access control for whole trees
access control for subsections of trees
backups
pushing to anoncvs
...

cvs assumptions / scripted usage in the tree

pkgsrc: changes-entry and commit-changes-entry
pkgsrc: guide regen
...