Annotation of wikisrc/users/dholland/hgpath.mdwn, revision 1.7
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
1.7 ! dholland 131: * rcsids in source files
! 132:
1.1 dholland 133:
134:
135:
136:
CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb