Return to gitsofar.mdwn CVS log

Up to [NetBSD Developer Wiki] / wikisrc

gitsofar: wikilink github

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