Re: Efficient cloning from svn (with multiple branches/tags subdirs)

From: Bruno Harbulot <bruno.harbulot@manchester.ac.uk>
Date: Oct 15, 2009, 17:23 UTC
Message-ID: <4AD75A93.9050106@manchester.ac.uk>
In-Reply-To: <32541b130910141126u4df7f439i3d2926c2e1db9497@mail.gmail.com>

Hello,

Avery Pennarun wrote:

Show 20 quoted lines

> On Wed, Oct 14, 2009 at 2:00 PM, Eric Wong <normalperson@yhbt.net> wrote:
>> Avery Pennarun <apenwarr@gmail.com> wrote:
>>> I've been thinking about this myself for some time.  One option that
>>> might be "interesting" would be to just grab the *entire* svn tree
>>> (from the root), and then use git-subtree[1] to slice and dice it into
>>> branches using your local copy of git (which is fast and uses no
>>> bandwidth) instead of during the svn fetch (which is slow and uses
>>> lots of bandwidth).  I think it would also simplify the git-svn code
>>> quite a lot, at least for fetching, since there would always be a
>>> global view of the tree and SVN things like "copy branch A to tag B"
>>> would just be exactly that.
>> This was actually the original use case of git svn back when I started.
>>
>>  git svn clone SVNREPO_ROOT   (without --stdlayout)
>>
>> It's still an option if you have the disk space for the working copies,
>> but I had to create the branches/tags support since the working copies
>> would be become prohibitively large.  If git-subtree could be
>> taught to work on a bare repo (git svn has a --no-checkout option)
>> it might be an option, too.

Thank you for your suggestions. Unfortunately, I'm not really familiar with git-subtree and how it could work with git-svn, sorry.

I've tried another workaround: using svnsync to pull the repository only once, and only then using git-svn fetch, locally, so as to avoid too much network traffic (I don't mind too much if it loops locally). I was hoping to be able to change the URL of the repository to the original one afterwards, but it doesn't seem to work so easily, because of the commit IDs. I'm assuming not having the same will cause problems for further fetches (this time directly from the original SVN repository) and for potential dcommits.

When I do this:
   git init
   git svn init -s --prefix=svn/ file:///path/to/local/restlet-svnroot
   git svn fetch -r 1:2

I get this ID, for example:
   r2 = c69a0b98d288a6e4e8779b50962b7fc65c4622e8

If I do this using the original http://restlet.tigris.org/svn/restlet, I 
get this:
   r2 = ce3b82915e92fe1ccf6ddedacd9d74b30bd4de86

I've even tried to install a Apache-based subversion server locally and make it believe it was restlet.tigris.org (by editing /etc/hosts and creating the appropriate VirtualHost), but this generates another SHA1 ID. (That's of course not a solution that would be generalisable.)

I've had a quick look at the git-svn code to see how this ID was generated, but couldn't find anything obvious. I realise this isn't the cleanest approach possible, but any suggestion would be appreciated.

Best wishes,

Bruno.