Steps for the SVN migration

[email protected] (Lars Strojny)
Newsgroups svn.migration
Message-ID <1217027891.7197.33.camel@localhost>
Hello everybody,

finally we decided to switch to Subversion, and I think we will not
regret. Nevertheless I like GIT, I think we should stop that discussion
for now and focus on getting the job done, which is, converting the CVS
repository to SVN. Though, there are a few open questions to decide and
to research:

Decisions
=========
1.) Do we want to use mod_dav_svn or svnserve, the subversion daemon?

Pro:
   * Allows to browse the repository with a normal webserver, very handy
   * Allows to use mod_authz_svn for fine grained access (different 
     format from the current format, but easily to read)
   * Is writable with normal WebDAV clients which might be a handy 
     feature for those, who do not want to bother with learning SVN
     (those who do documentation translations, website updates, etc.)

Contra:
   * Might be slower
   * Forces us to use Apache 2, which we, as I heard, currently do not 
     use

2.) Single repository, multiple repositories. Do we want to use a single
repository for all things PHP, including PEAR, PECL etc.?

Pro:
   * It is how it is currently
   * Only one repository to maintain and administer (e.g. hooks are 
     configured for everything or for nothing)

Contra:
   * Multiple repositories might be easier to scale, as they can be 
     distributed on various hosts. Not sure if this is likely to become 
     an issue
   * Easier to include new projects and to move current projects to 
     another hosts if the situation requires such a change
   * One repository itself does not become that huge and can be shared 
     over partitions, discs (while this is possible with symlinking old 
     revision data too, it is not very handy)

3.) Directory structure: We will have the classical layout
(branches/tags/trunk), but what about subdirectories in tags like
releases, and feature tags. What about a developer folder in branches to
allow developer specific branches?

4.) Do we want to sync to CVS in the first time with a hook to allow use
to switch back just in case of an unforeseeable failure with the
Subversion repository?

Research
========
     1. How fast ist mod_dav_svn + Apache2 in comparison to svnserve?
        How many concurrent reads/writes?
     2. What would be the alternative to mod_authz_svn if we decide to
        use svnserve?
     3. How can we improve the speed of the conversion process to make
        the outage of the tree as short as possible. Does Gwynne need
        hardware help here, can we provide resources (machines) to help?
     4. What scripts to work with CVS are there, how can they be
        converted to work with Subversion?
     5. Experience of other Open Source/Free Software projects switching
        to Subversion, e.g. GNOMEs switch comes in my mind. What did
        they learn what we can do right from the beginning?

If we have answered and worked out this questions, we can create a
timeline and do the migration.

So, a lot to discuss :)

cu, Lars
signature.asc (application/pgp-signature, 835 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)

iQIcBAABAgAGBQJIil8zAAoJECQPF+sCY6wHtUAP/0EqKrsvP5G+ebCK7cxd+eNd
wxf6SEiZKwlrxAnK24QVCKynDj8AIzRrU2OvolJqsbTBee2Sn87c25JsLY252VxH
UM5k/dck5kSsMtbd3hjGpNgBhWF/Knh8e2DBuLcPcZ83WAQzs9/Ykrs0G6/BoarY
MgNUzKeYH2F3eRDjtsEMJLREqMkASq9zH++Y/Xn9mnU0P+QNwoLHTAcfcyi3LizF
gEniLCqNzAcBa6Qsmmki8mn+LOM2a7JSnsRATQehELw08o3XAfcDhGAh+2nuK56T
Y7Vpr3azJJFYKLZTNWJkxCvifYJ2pdXDPoViWWZnxvR9voBaq+MWyuYNkkMRQ21R
XmzFv+Co0CCKHLpwTxxDSt99KpOYDvrZmFEOYPjDMOFQBbl4HtBIo0f+L86Ktz8N
9dTj6RexeIEL85OqsIe3WAREB3Im1LWIcmpIMF01C0koyFujVQhfGvI9LJ+mTEJA
HTjHe30tdX0OLEjBqMWQTMHkt3G9Fk5mALJIeUFk2UFJOw5fLmS3th0tnY6UEq1U
YS1QfmbwCf0U7GOiQWaHcHkQfI+hDDylQqAuknV3ZIs0Pqkn1vyEq684vqbfaVHx
Dg7K1yIODstm9ETLly92ouZJl63YMyyV3gCd8SGp6pEkTtY8eXOC9Umlgk4cWUWs
XuEyxT4412ZxdY1OWMO5
=ScNH
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.