Re: [SVN-MIGRATION] Argh!

On Jul 11, 2009, at 12:24 PM, Rasmus Lerdorf wrote:

Travis Swicegood wrote:

That's actually a *really* bad idea. There are a lot of third-party tools that rely on the standard SVN repository layout that this will break. It would be much easier to write a few simple scripts to handle checkouts of multiple repositories or as Hannes pointed out use svn:externals with a few repositories such as pecl-all might also be a good solution.

What sort of 3rd party tools? I'm more worried about our own 1st party tools that are currently completely broken because of this structure.

Well, off of the top of my head it becomes much, much harder to do a git svn clone on it. :-) I believe, though I'm not positive since I don't use them on a regular basis, that most GUIs would be broken as well. Subversion doesn't have a real concept of a branch or a tag. They're all just copies of code, so they use a convention in the file-system to denote what's what. Most 3rd-party apps are going to rely on it to show things like branches and tags and whatnot.

We also have to find a good way to do what cvsup did for our cvs repository. rsync.php.net fetches most of the repository and keeps a copy for serving up via rsync to mirror sites and all sorts of tools. That is obviously broken right now. Watching the pathetic performance of svn over http last night, that is definitely not an option. We need an efficient way to clone the repository. Step 1 might be to get svnserve set up and perhaps that would be quick enough to let us do a straight periodic update from the rsync server.

When I've had to mirror remotely I've used SVK. That's always been done where I don't have access to the file system on one of the machines though (i.e., making a copy of a Google Code repo, or some such). I assume we have to the rsync.php.net machine, so why not just do an rsync of the repository files on svn.php.net? -T