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