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