Thread (9 messages) flat view 9 messages, 4 authors, 2016-06-15

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

From: B Smith-Mannschott <hidden>
Date: 2016-06-15 22:47:33

On Thu, Oct 15, 2009 at 19:23, Bruno Harbulot
[off-list ref] wrote:
Hello,

Avery Pennarun wrote:
quoted
On Wed, Oct 14, 2009 at 2:00 PM, Eric Wong [off-list ref] wrote:
quoted
Avery Pennarun [off-list ref] wrote:
quoted
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.
When I 'git svn clone' from a svnsync mirror I pass
--use-svnsync-props. Have you tried that?

// Ben
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help