Subversion problems

[heiko.evermann at gmx.de]

Moin Stephan,

> 2. My original plan was to migrate modules in chunks, so that we can play
> around with e.g. kdenonbeta and kdeextra*+kdeplay* and then after two weeks
> or so migrate code and then after another two weeks migrate kde-i18n - or
> so. But there are several problems with that: a) while a module is loaded
> into the subversion repository, we have to disable subversion access as
> svnadmin load doesn't seem to lock, so we would have a blocked cvs and a
> blocked svn at that and I kind of would prefer a one time blocking. b) [the
> bigger one] subversion is majorly confused if revisions are not in
> chronologic order. From what the svn developers told me, this is a
> non-trivial bug and not expected to be fixed any time soon. This would lead
> to the problem that you can't checkout by date and possibly never will be.
> This is in general no loss of functionality as you can still check by svn
> log what revision you want and then co by revision. It's still ugly.
>    So I'm in the progress of testing the performance of a full repository
> conversion and so far it looks like we could finish the full conversion in
> say a week. For this time we had no source control at all while with the
> module by module conversion we had outages of several hours spread over a
> month.
I think that should not matter. From the previous posts I got the impression 
that quite a number of developers really wants subversion. So how about that:
1) practise with one or two modules, cvs remains master, svn is just used as a 
test
2) when that works well: convert everything from cvs to svn, cvs remains 
master, svn is just a playground. Let it run as long as it takes.
3) Make sure that KDE compiles, to check that the conversion did work. Try 
this for HEAD and one or two older branches.
4) When all works well, cvs will be locked, the conversion will take place. 
svn becomes master. The downtime will be announced in time, and we will be 
able to live with one week of downtime.

Kind regards,

Heiko Evermann

>
> Now I would like to have some input on the problems we face. Would you
> prefer to not loose the date<->revision mapping or doesn't it matter?
>
> Greetings, Stephan