File:  [NetBSD Developer Wiki] / wikisrc / gitsofar.mdwn
Revision 1.6: download - view: text, annotated - select for diffs
Mon Feb 16 08:36:53 2015 UTC (5 years, 1 month ago) by khorben
Branches: MAIN
CVS tags: HEAD
Also mention IIJ

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

CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb