version 1.8, 2015/01/19 13:31:33
|
version 1.9, 2016/02/15 23:02:07
|
Line 1
|
Line 1
|
## NetBSD migration path to Mercurial |
## NetBSD migration path to Mercurial |
|
|
This page describes what's involved in migrating NetBSD from CVS to |
This page has been [[moved|http://www.netbsd.org/~dholland/notes/hg-migration/path.html]]. |
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 who's pushing |
|
what, e.g. using the |
|
[[pushlog|http://hg.mozilla.org/hgcustom/version-control-tools/summary]] |
|
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 |
|
* ... |
|
|
|
Other questions |
|
|
|
* running live in parallel with CVS during a transition period |
|
* gatewaying to other VCS frontends |
|
* rcsids in source files |
|
|
|
|
|
|
|
|
|
|
|