|
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 |
|
| |
|
| |
|
| |
|
| |
|
| |
|
![[BACK]](/icons/back.gif){kind=icon}
Return to hgpath.mdwn CVS log ![[TXT]](/icons/text.gif){kind=icon}
![[DIR]](/icons/dir.gif){kind=icon}
Up to [NetBSD Developer Wiki] / wikisrc / users / dholland