Annotation of wikisrc/gitsofar.mdwn, revision 1.8
1.2 mspo 1: ## NetBSD with git so far
1.1 mspo 2:
1.8 ! cnst 3: * [2015-01: Core statement on version control systems](http://mail-index.netbsd.org/tech-repository/2015/01/04/msg000497.html)
! 4: * [2017-06: New home for the repository conversion](http://mail-index.netbsd.org/tech-repository/2017/06/10/msg000637.html)
! 5: * [2017-09: pkgsrc Commit Message Policy](http://mail-index.netbsd.org/pkgsrc-users/2017/09/12/msg025574.html)
! 6: * [GitHub.com/NetBSD](https://github.com/NetBSD)
1.1 mspo 7:
1.2 mspo 8: ### Low memory hosts:
9:
10: * [tuning for git on low memory](http://mail-index.netbsd.org/tech-repository/2015/01/08/msg000520.html)
1.1 mspo 11:
12: git appears to have slightly different memory characteristics depending on the
13: protocol used. Over http I am able to get a full clone with all history on a
14: 256 + 256 raspberri pi. If you bump up the memory to 512 + 256 it makes ssh
15: possible, which means writes are possible.
16:
17: The link above has some tuning I used to get memory requirements way down.
18:
19: It should be noted that git support a "shallow" clone (--depth 1) which ignores
20: most history but allows commits and full development.
21: A shallow clone works on very small systems; I would guess 128MB + a little swap
22: is enough.
23:
24: git is slow during 'status' by default since it searches the entire tree for a
25: change. It will produce a warning with tunable options if the command runs
26: slowly.
27:
1.5 wiki 28: *Update*
29:
1.4 mspo 30: After some complaining on the git@ mailing list a patch has been produced which
31: drops the memory requirements down quite a bit. I can now, without much tuning,
1.7 wiki 32: work on my 512 system.
1.4 mspo 33:
1.2 mspo 34: ### CVS in parallel
35:
1.1 mspo 36: I do not think this is a good idea and do not plan to advocate for it.
37: Git does have a cvs server built-in but I have not taken the time to set it up
38: for testing because it is slightly involved and I don't see the purpose.
39:
1.2 mspo 40: ### Conversion
41:
1.1 mspo 42: One-shot to create the new True Source. I don't think there will be many cvs
43: hold-outs.
44:
45: See above for CVS server provided if ongoing conversion is really desired.
46:
1.2 mspo 47: ### existing cvs dependencies
48:
1.7 wiki 49: is there a list of these? build systems?
50: The entire build infrastructure of NetBSD should (even without giti) change into a "jobs"-oriented workflow instead of a "server"-oriented workflow.
51:
52: Very recent (summer 2017) events have shown that the ability to move things around is very important.
53:
1.1 mspo 54:
1.2 mspo 55: ### How should NetBSD be setup
56:
1.1 mspo 57: High level- private box for write master using ssh, any number of additional
58: systems with read-only mirrors over http:// and git://
59:
1.3 mspo 60: Also see a great description of how DragonflyBSD is setup:<br>
61: [dfbsd server setup](http://lists.dragonflybsd.org/pipermail/users/2015-January/207421.html)<br>
62: [dfbsd workflows](http://lists.dragonflybsd.org/pipermail/users/2015-January/207422.html)<br>
63: [dfbsd config](http://lists.dragonflybsd.org/pipermail/users/2015-January/207424.html)<br>
1.2 mspo 64:
1.8 ! cnst 65: [In 2019, FreeBSD core team has appointed a WG to explore transition from Subversion to Git.](https://www.freebsd.org/news/status/report-2019-04-2019-06.html#FreeBSD-Core-Team)
! 66:
1.2 mspo 67: ### how to install
1.1 mspo 68:
69: git should fit into NetBSD src/tools easily. I have not personally tested
70: cross compilation.
71:
1.2 mspo 72: ### workflows
73:
1.1 mspo 74: See DragonflyBSD examples given above
75:
76: There are many many workflows supported in git. For the most part I think
77: NetBSD developers would follow the "feature branch" workflow from the main repo
78: (or private/semi-private clones before merge).
79:
80: Public collaboration is a big feature of git since it can format patches into
81: at least two different email formats and they can be submitted to a bug report
82: or to a mailing list, which should allow clean apply.
83:
84: A non-developer could also post a pull request to github or host his git repo
85: for a friendly developer to add as an origin and pull his branch.
86:
87: (git origin add future-developer http://example.com/~greatguy/src.git)
88:
89:
1.2 mspo 90: ### log message formats
91:
1.4 mspo 92: Try to references named branches/tags instead of sha-1's
1.1 mspo 93: Also using the dates for commits instead of commit id's
94:
1.2 mspo 95: ### how to convert
96:
1.7 wiki 97: https://github.com/netbsd/
1.1 mspo 98:
1.2 mspo 99: ### No lock-in
100:
1.1 mspo 101: I am unable to anticipate the next generation of SCM.
102: Don't do anything weird like change history and we should be fine.
103:
104: Maybe when we have 30 years of project history it will be time to consider
105: restructuring the project. :)
106:
1.7 wiki 107: git is the most widely used VCS ever so it has the best chance of conversion tools existing.
108: No future tool will be able to exist without a git-conversion script.
109:
1.4 mspo 110: ---
111:
112: I think this is less a function of the tool and more a function of the project not
113: allowing non-"standard" actions.
114:
1.2 mspo 115: ### Who, When, and How Long?
116:
1.6 khorben 117: * ESR/IIJ/Joerg - convert
1.1 mspo 118: * sometime, eventually, maybe
1.4 mspo 119: * assumptions/proposal:
120:
121: Assuming conversion starting from date(x) to freeze(y) is relatively easy, the
122: refinements of Joerg/ESR conversion can continue to run in read-only mode as they
123: do today. This means the "switch" is a few hours only for:
124:
1.5 wiki 125: 1. cvs goes read only
126: 2. history from last git conversion pull until now is appended
127: 3. cvs is turned off
128: 4. git is made available over ssh
129:
CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb
![[BACK]](/icons/back.gif){kind=icon}
Return to gitsofar.mdwn CVS log ![[TXT]](/icons/text.gif){kind=icon}
![[DIR]](/icons/dir.gif){kind=icon}
Up to [NetBSD Developer Wiki] / wikisrc