## NetBSD migration path to Mercurial

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

### What Mercurial is

[[Mercurial|http://mercurial.selenic.com]] 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|hgtodo]] 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|hgnb]].

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_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
* ...

Other questions

* running live in parallel with CVS during a transition period
* gatewaying to other VCS frontends
* rcsids in source files