Why SVN:
 - Package Sets
 - Easier tagging. Maybe branching in the future
 - Easier repo copies
 - One VCS for the whole project
 - It fits all our needs
 - Disadvantages:
 But forced
  shouldn't be necessary with SVN very often
 Inefficient repository (size)
 
 Why not git:
 could lead to problems with a large number
  of committers)
 - hash problem
 - No partial checkouts
 - See http://wiki.freebsd.org/GitDrawbacks for more informations
 
 Repo growth:
 - Written simulation shows that repo will grow more the CVS but is still
  acceptable.
 - Other known open source projects have repository of 100GB and it
  still works. (This is 7 times the size of the ports repo).
 
 History:
 - We will convert the whole history
 - It is an important tool to work with
 - We don't want to repo for searching the history as I'd like to get rid of
  CVS in the future completely
 - Downside repo size (but clusteradm@ is ok with that)
 
 Exporter:
 - We will have an CVS exporter
 - Many users and companies still rely on cvsup
 - If you like to mirror the repo and you are concerned about the repo size
  use cvsup
 
 Users and project space:
 - None of both as they aren't used by many committers in src and add a
  lot of outdated code.
 - We have teams with non-committer contributors
 - A lot of free repos available
 
 Current status:
 - Test repo set up
 - Anonymous access via svn & http
 - Committers access through ssh
 - Snapshot tarball of trunk available for download
 - CVS exporter running
 - git snapshot available
 - Contact me for location information about the test repo
 - Wiki page with documentation
 
 Current work:
 - Wrapper script with keyword support
 - Make git work with keywords
 
 Roadmap:
 - Testers welcome and needed
 - Open tasks in the wiki
 - Conversion done this summer (depends on testing effort done)
 
 Outcome of discussions and work done at the DevSummit:
 - Had a look at the CVS exporter problems with peter@ and wrote a hook
  to prevent exporter breakage (tested with flo@)
 - simon@ pointed me at "svnadmin pack". This reduced the repo size by
  100MB and reduced the number of used inodes by 50%!
 Some tests done. Size
  increased by 100MB but still not decided who to handle them correctly.
  (I don't want to have stale CVS IDs on files). Some options are available
  to handle this but I haven't decided yet.
 - The svn wrapper is written which makes some sanity checks and handles all
  the keyword magic.
 - flo@ made a test to run the svn import on bear2 with a FusionIO card which
  lowered the import time from 2 days down to 3 hour!
 - Some SVN keywords weren't applied correctly by cvs2svn. A patch for
  cvs2svn was written to fix this.
 - swills@ contacted some Subversion developers via (pgollucci@). Subversion
  trunk should reduce the repo size and should be backwards compatible with
  Subversion 1.7. Two test imports were done with Subversion trunk but the
  saved repo size was only a couple of hundred MBs so it's not worth to do the
  import with a different Subversion version.

- Was in contact with the FreeBSD git crew regarding the SVN keyword. There
is nothing I can help to make this work.

 I'm almost ready for the conversion (biggest missing parts are porters
 handbook and committers guide patches) but I really need more testers!
 
 Feel free to contact me if you have any questions regarding SVN or the
 conversion.
 
 ===
 
 Thanks,
 Beat