--- wikisrc/gitsofar.mdwn 2015/02/01 02:30:33 1.2
+++ wikisrc/gitsofar.mdwn 2019/09/03 01:16:05 1.10
@@ -1,6 +1,13 @@
## NetBSD with git so far
-[core statement on vcs](http://mail-index.netbsd.org/tech-repository/2015/01/04/msg000497.html)
+* [[mailing-lists/tech-repository]]
+* [[projects/project/cvs-migration]]
+* [[github]]
+* [2011-10: Fossilizing NetBSD: The road to modern version control](https://2011.eurobsdcon.org/papers/sonnenberger/fossilizing.pdf)
+* [2015-01: Core statement on version control systems](http://mail-index.netbsd.org/tech-repository/2015/01/04/msg000497.html)
+* [2017-06: New home for the repository conversion](http://mail-index.netbsd.org/tech-repository/2017/06/10/msg000637.html)
+* [2017-09: pkgsrc Commit Message Policy](http://mail-index.netbsd.org/pkgsrc-users/2017/09/12/msg025574.html)
+* [GitHub.com/NetBSD](https://github.com/NetBSD)
### Low memory hosts:
@@ -22,6 +29,12 @@ git is slow during 'status' by default s
change. It will produce a warning with tunable options if the command runs
slowly.
+*Update*
+
+After some complaining on the git@ mailing list a patch has been produced which
+drops the memory requirements down quite a bit. I can now, without much tuning,
+work on my 512 system.
+
### CVS in parallel
I do not think this is a good idea and do not plan to advocate for it.
@@ -37,17 +50,23 @@ See above for CVS server provided if ong
### existing cvs dependencies
-TBD
+is there a list of these? build systems?
+The entire build infrastructure of NetBSD should (even without giti) change into a "jobs"-oriented workflow instead of a "server"-oriented workflow.
+
+Very recent (summer 2017) events have shown that the ability to move things around is very important.
+
### How should NetBSD be setup
High level- private box for write master using ssh, any number of additional
systems with read-only mirrors over http:// and git://
-Also see a great description of how DragonflyBSD is setup:
-[dfbsd server setup](http://lists.dragonflybsd.org/pipermail/users/2015-January/207421.html)
-[dfbsd workflows](http://lists.dragonflybsd.org/pipermail/users/2015-January/207422.html)
-[dfbsd config](http://lists.dragonflybsd.org/pipermail/users/2015-January/207424.html)
+Also see a great description of how DragonflyBSD is setup:
+[dfbsd server setup](http://lists.dragonflybsd.org/pipermail/users/2015-January/207421.html)
+[dfbsd workflows](http://lists.dragonflybsd.org/pipermail/users/2015-January/207422.html)
+[dfbsd config](http://lists.dragonflybsd.org/pipermail/users/2015-January/207424.html)
+
+[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)
### how to install
@@ -74,12 +93,12 @@ for a friendly developer to add as an or
### log message formats
-Try to references named branches instead of sha-1's
+Try to references named branches/tags instead of sha-1's
Also using the dates for commits instead of commit id's
### how to convert
-ESR?
+https://github.com/netbsd/
### No lock-in
@@ -89,8 +108,26 @@ Don't do anything weird like change hist
Maybe when we have 30 years of project history it will be time to consider
restructuring the project. :)
+git is the most widely used VCS ever so it has the best chance of conversion tools existing.
+No future tool will be able to exist without a git-conversion script.
+
+---
+
+I think this is less a function of the tool and more a function of the project not
+allowing non-"standard" actions.
+
### Who, When, and How Long?
-* ESR/Joerg - convert
+* ESR/IIJ/Joerg - convert
* sometime, eventually, maybe
-* unknown
+* assumptions/proposal:
+
+Assuming conversion starting from date(x) to freeze(y) is relatively easy, the
+refinements of Joerg/ESR conversion can continue to run in read-only mode as they
+do today. This means the "switch" is a few hours only for:
+
+1. cvs goes read only
+2. history from last git conversion pull until now is appended
+3. cvs is turned off
+4. git is made available over ssh
+