Subversion problems
Stephan Kulow
coolo at kde.org
Thu Feb 17 09:10:19 GMT 2005
Hi!
While doing more detailed experiments with subversion, we found two strategic
problems with it:
1. kde-common/admin - the support for svn:externals is in no way comparable to
what we did with CVS's modules: a) we can't have no way to use use relative paths
there, so we need to add a external property to all branches and tags using e.g.
a full https URL - most likely anonymous, that even ssh users would have to check out.
b) I didn't find a way to do add such a property without checking out all branches/tags
and honestly: I'm not going to do that.
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.
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
More information about the kde-core-devel
mailing list