Diff for /wikisrc/users/dholland/hgpath.mdwn between versions 1.8 and 1.9

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]].
 ### 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  
 ### 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  
   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  

Removed from v.1.8  
changed lines
  Added in v.1.9

CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb