Problems with cvs2svn (git) conversion:

* Conversion takes a lot of time (>24hrs) and memory
  - One-time only, minimal issue

* Cloning the new tree takes server tremendous resources due to bugs in git
  - Robin has done a lot of work with upstream in fixing this
  - Will the optimized git release and git tree use more or less resources than
    our current CVS tree?

* Cloning the new tree requires a lot of bandwidth and disk space
  - 9 years worth of history
  - Heavily unoptimized due to cvs2svn (git) conversion
    + Explained in detail in the next section
  - A lot of devs still behind slow connections
    + Might end up being slower than cvs for such people
  - Resume support is coming, will alleviate the issue of bandwidth
  - Sparse clones would alleviate the issue of disk space
    + No time-frame for when they would come
  - Variable depth clones are useless for devs right now
    + Tied to sparse clones

* Why is the gentoo-x86.git tree so huge?
  - History is filled with keyword-related commits
    + Useless in the long-run
    + Except for statistics
  - CVS resets the history of a file as soon as it's renamed (revbump)
    + git manages content, and would ideally be able to manage it *very*
      efficiently
    + cvs2svn does not detect content moves => very very inefficient
      * For a package with active upstream, ebuild history gets reset every
        fortnight
  - None of the uses of ebuild history justify forcing every developer to lug it
    around on their disks

* Proposal
  - "Flat" import gentoo-x86, archive CVS for it's history
  - "gentoo" tree and other cvs trees can be converted to git
    + Do not suffer from the problems that gentoo-x86 has
    + Few renames, mostly modifications
    + CVS can _also_ be archived for consistency