Annotation of wikisrc/users/dholland/hgpath.mdwn, revision 1.6

1.1       dholland    1: ## NetBSD migration path to Mercurial
                      2: 
                      3: This page describes what's involved in migrating NetBSD from CVS to
                      4: Mercurial.
                      5: 
                      6: ### What Mercurial is
                      7: 
                      8: [[Mercurial|http://mercurial.selenic.com]] is an open-source version
                      9: control system.
                     10: It is a distributed version control system based on the commit
                     11: hashcode model shared with git and other DVCSes.
                     12: It is fast and powerful and has long emphasized a certain polish of
                     13: production.
                     14: 
                     15: ### Why Mercurial
                     16: 
                     17: Mercurial is a modern VCS; it is maintained; it is capable of
                     18: handling the NetBSD repositories; and it is cleanly designed, simple,
                     19: and easy to use.
                     20: The first three of these properties are necessary requirements for
                     21: NetBSD to migrate (I don't think any of them are particularly
                     22: controversial); the last sets it apart from git, which is the other
                     23: immediately available alternative.
                     24: (The third option, writing our own, is not currently realistic.)
                     25: 
                     26: One could write a lot of gung-ho IT IS REALLY GR8!!!11!! boosterism
                     27: here too, of course, but I'll leave that for someone else.
                     28: 
                     29: ### Migration
                     30: 
                     31: There are two categories of issues related to migrating a project the
                     32: size of NetBSD: first, what the project and the world around the
                     33: project will look like after the migration is done, and second, what
                     34: things need to be done to get there.
                     35: The purpose of this page is to tackle the first: what things in the
                     36: project will be different and what they'll be like.
                     37: This includes not just user-facing things like commit procedures but
                     38: also backend considerations and administration.
                     39: 
1.4       dholland   40: There's a [[second page|hgtodo]] with a list of work that needs
1.1       dholland   41: to be done.
                     42: 
                     43: ### Issues
                     44: 
                     45: Technical concerns (demands on the system's operational model)
1.2       dholland   46: 
1.1       dholland   47: * atomic commits / changesets
                     48: * rename support
                     49: * authenticating commits
                     50: * numbered versions
                     51: * branch handling
                     52: * tag handling
1.5       dholland   53: * partial checkouts (partial trees, partial history)
1.1       dholland   54: * blacklist extension (which is a legal requirement)
                     55: * being able to migrate away in the future
                     56: * ...
                     57: 
                     58: Conversion of CVS repository phenomena
1.3       dholland   59: 
1.1       dholland   60: * vendor branches
                     61: * conversion of repo-copies and similar CVS horrors
                     62: * adding rename metadata to already-done moves
                     63: * pkgsrc not-really-vendor imports
                     64: * developer usernames vs. email addresses in log messages and commit metadata
                     65: * non-ascii text in log messages
                     66: * version references in log messages
                     67: * retaining CVS file version numbers as metadata
1.6     ! dholland   68: * restoring the pre-USL-settlement history and/or including the CSRG history
1.1       dholland   69: 
                     70: Implementation concerns (demands on the system as it exists)
1.3       dholland   71: 
1.1       dholland   72: * general performance
                     73: * importing into base, or not
                     74: * storage requirements vs. small systems
                     75: * memory requirements vs. small systems
                     76: * possible workarounds for small systems
                     77: * ...
                     78: 
                     79: Community deployment issues
1.3       dholland   80: 
1.1       dholland   81: * what becomes of anoncvs
                     82: * making use of version numbers in mailing lists / security advisories
                     83: * patches/contributions/commits from non-developers
                     84: * collaborating with non-developers
                     85:   
                     86: Developer deployment issues
1.3       dholland   87: 
1.1       dholland   88: * commit procedures
                     89: * development branch procedures
                     90: * vendor branch procedures
                     91: * private branch procedures
                     92: * collaboration without pushing to the master repositories
                     93: * rebasing vs. merging
                     94: * how to refer to other commits in log messages
                     95: 
                     96: Many of these issues are already documented in [[the existing
1.6     ! dholland   97: workflows writeup|hgnb]].
1.1       dholland   98: 
                     99: Releng deployment issues
1.3       dholland  100: 
1.1       dholland  101: * changes to the way pullups are filed
1.6     ! dholland  102: * adjusting processing scripts for new source-changes format
1.1       dholland  103: * release commit procedures
                    104: * release branch procedures
                    105: * dealing with accidental commits to release branches
                    106: * preventing accidental merges into release branches
                    107: * extracting formal release tarballs
                    108: * shipping source tarballs
                    109: * ...
                    110: 
                    111: Backend/admins deployment issues
1.3       dholland  112: 
1.6     ! dholland  113: * how commits get pushed to the master tree
1.1       dholland  114: * log_accum / source-changes mails
                    115: * access control for whole trees
                    116: * access control for subsections of trees
                    117: * backups
                    118: * pushing to anoncvs
                    119: * ...
                    120: 
                    121: cvs assumptions / scripted usage in the tree
1.3       dholland  122: 
1.1       dholland  123: * pkgsrc: changes-entry and commit-changes-entry
                    124: * pkgsrc: guide regen
                    125: * ...
                    126: 
                    127: Other questions
1.3       dholland  128: 
1.1       dholland  129: * running live in parallel with CVS during a transition period
                    130: * gatewaying to other VCS frontends
                    131: 
                    132: 
                    133: 
                    134: 

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