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-----