1: == NetBSD with git so far
5: === Low memory hosts:
6: * http://mail-index.netbsd.org/tech-repository/2015/01/08/msg000520.html
8: git appears to have slightly different memory characteristics depending on the
9: protocol used. Over http I am able to get a full clone with all history on a
10: 256 + 256 raspberri pi. If you bump up the memory to 512 + 256 it makes ssh
11: possible, which means writes are possible.
13: The link above has some tuning I used to get memory requirements way down.
15: It should be noted that git support a "shallow" clone (--depth 1) which ignores
16: most history but allows commits and full development.
17: A shallow clone works on very small systems; I would guess 128MB + a little swap
18: is enough.
20: git is slow during 'status' by default since it searches the entire tree for a
21: change. It will produce a warning with tunable options if the command runs
24: === CVS in parallel
25: I do not think this is a good idea and do not plan to advocate for it.
26: Git does have a cvs server built-in but I have not taken the time to set it up
27: for testing because it is slightly involved and I don't see the purpose.
29: === Conversion
30: One-shot to create the new True Source. I don't think there will be many cvs
33: See above for CVS server provided if ongoing conversion is really desired.
35: === existing cvs dependencies
38: === How should NetBSD be setup
39: High level- private box for write master using ssh, any number of additional
40: systems with read-only mirrors over http:// and git://
42: Also see a great description of how DragonflyBSD is setup:
47: === how to install
48: git should fit into NetBSD src/tools easily. I have not personally tested
49: cross compilation.
51: === workflows
52: See DragonflyBSD examples given above
54: There are many many workflows supported in git. For the most part I think
55: NetBSD developers would follow the "feature branch" workflow from the main repo
56: (or private/semi-private clones before merge).
58: Public collaboration is a big feature of git since it can format patches into
59: at least two different email formats and they can be submitted to a bug report
60: or to a mailing list, which should allow clean apply.
62: A non-developer could also post a pull request to github or host his git repo
63: for a friendly developer to add as an origin and pull his branch.
65: (git origin add future-developer http://example.com/~greatguy/src.git)
68: === log message formats
69: Try to references named branches instead of sha-1's
70: Also using the dates for commits instead of commit id's
72: === how to convert
75: === No lock-in
76: I am unable to anticipate the next generation of SCM.
77: Don't do anything weird like change history and we should be fine.
79: Maybe when we have 30 years of project history it will be time to consider
80: restructuring the project. :)
82: === Who, When, and How Long?
83: * ESR/Joerg - convert
84: * sometime, eventually, maybe
85: * unknown
CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb