From: Björn Steinbrink <b.steinbrink@gmx.de>
Date: Sat, 15 Aug 2009 18:16:37 GMT
Subject: Re: git-svn bug report: %20 in http:// should translate to a space ' ' automatically
Message-ID: <20090815181637.GC19833@atjola.homenet>
In-Reply-To: <4A86F4DA.5090605@smullindesign.com>

On 2009.08.15 11:48:10 -0600, Mike Smullin wrote:
> Hello,
> 
> This one took me over an hour to figure out with the help of doener
> in #git on irc.freenode.net:

[IRC log omitted]

To wrap that up:

1) git svn clone http://host/repo/path%20with%20spaces/foo/bar/goo

Works, but see below.

2) git svn clone -Tgoo http://host/repo/path%20with%20spaces/foo/bar

Fails.

3) git svn clone -Tgoo "http://host/repo/path with spaces/foo/bar"

Works.


In Mike's case, there was a rename from foo/goo to foo/bar/goo. 1) fails
to follow that rename, 2) just completely fails and 3) works and follows
the rename.

Cloning via http:// didn't provide any interesting error messages, but
cloning via svn+ssh:// showed:

For 1)
W: Ignoring error from SVN, path probably does not exist: (160013):
Filesystem has no item: File not found: revision 100, path
'/path with spaces/foo/bar"

For 2)
W: Ignoring error from SVN, path probably does not exist: (160013):
Filesystem has no item: File not found: revision 100, path
'/path%20with%20spaces/foo/bar"


So 2) somehow has the spaces escaped there, but 1) doesn't.

I guess that 1) has it right, and the rename detection just doesn't work
because the old name is outside of "url" for the svn-remote. And 2)
somehow gets it wrong, likely double-escaping the spaces or so. (I have
no idea...)

My totally uneducated guess is that git-svn fails to unescaped the path
when it splits it into the higher-level part for "url" and the rest of
it for "fetch".

HTH
Björn