Re: [SVN-MIGRATION] Steps for the SVN migration

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

Moving things over to Apache2 isn't hard.  I installed it last night. 
It's just a matter of finishing up migrating the configuration over and 
recompiling PHP for it.  But yes, if the speed penalty is significant, 
that is a problem.  Our previous CVS server was slow and it was a pain 
in the ass.

> 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

With CVS this was never an issue and we have 12+ years of development in it.

>     * Easier to include new projects and to move current projects to
>       another hosts if the situation requires such a change

Moving a directory out of CVS to some other repository was never hard. 
We did it a couple of times.

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

Again, 12+ years of development and our raw CVS repository is 5G.  So 
let's say we are twice as productive/verbose over the next 12 years, 
that would mean we will grow to 15G.  Hell, multiply that by 10 and it 
is still only 150G.  Nothing by today's standards, and completely 
insignificant in 5 years.

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

Can the conversion be distributed somehow?  The end result should end up 
on the current cvs machine.  It has penty of juice to run subversion 
nicely, but if we can somehow distribute the actual conversion of the 
repository somehow, that would be cool.  I seriously doubt that exists 
though.

-Rasmus