threads / bug / 26568

[BUG] git-svn fails to rename files with %20 in filename

Subject: [BUG] git-svn fails to rename files with %20 in filename

## tl;dr

6 messages between Feb 21, 2011 and Mar 2, 2011.

replies: 5people: 3as markdown or json

Will Palmer· Feb 21, 2011, 10:12 UTC · lore

Someone accidentally checked some files containing "%20" in their names into our svn repository, which is accessed with either svn or git-svn depending on the developer. When I attempted to correct this by renaming the file, I received (on dcommit): Filesystem has no item: File not found: revision 1, path '/theBeginningOfTheOriginalFileName theRestOfTheOriginalFilename' at /home/wpalmer/libexec/git-core/git-svn line 576

A recipe for reproducing this bug is as follows:
#!/bin/bash
temp="$(mktemp -t -d 'git-svn.XXXXXXXXXX')"
[ -n "$temp" ] || { echo "Failed to create temporary directory" >&2;
exit 1; }
function _cleanup(){
	rm -rf "$temp"
}
trap _cleanup INT EXIT
cd "$temp" || exit 1

set -x svnadmin create svn-repos && svn co file://$PWD/svn-repos svn-wc && cd svn-wc && touch 'foo%20bar' && svn add 'foo%20bar' && svn ci -m 'add foo%20bar' && cd .. && git svn clone file://$PWD/svn-repos git-wc && cd git-wc && git mv 'foo%20bar' 'foo-bar' && git commit -m 's/%20/-/ in filename' && git svn dcommit # BUG HERE

Jeff King· Feb 21, 2011, 12:31 UTC · re: Will Palmer · lore

Re: [BUG] git-svn fails to rename files with %20 in filename

On Mon, Feb 21, 2011 at 10:12:24AM +0000, Will Palmer wrote:
Show 11 quoted lines
> Someone accidentally checked some files containing "%20" in their names
> into our svn repository, which is accessed with either svn or git-svn
> depending on the developer.
> When I attempted to correct this by renaming the file, I received (on
> dcommit):
> Filesystem has no item: File not found: revision 1, path
> '/theBeginningOfTheOriginalFileName theRestOfTheOriginalFilename'
> at /home/wpalmer/libexec/git-core/git-svn line 576
> 
> A recipe for reproducing this bug is as follows:
> [...]

Thanks for the thorough test case. It seems to pass for me if with this applied:

diff --git a/git-svn.perl b/git-svn.perl
index 177dd25..7daf63c 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -4556,9 +4556,7 @@ sub repo_path {
 
 sub url_path {
 	my ($self, $path) = @_;
-	if ($self->{url} =~ m#^https?://#) {
-		$path =~ s!([^~a-zA-Z0-9_./-])!uc sprintf("%%%02x",ord($1))!eg;
-	}
+	$path =~ s!([^~a-zA-Z0-9_./-])!uc sprintf("%%%02x",ord($1))!eg;
 	$self->{url} . '/' . $self->repo_path($path);
 }
 

IOW, it looks like the path we hand to svn needs url-encoding even for
the local case (which make sense, as it is a file:// url). But I know
nothing about svn, so probably I am breaking some other weird non-url
local case. :)

-Peff
Will Palmer· Feb 22, 2011, 16:50 UTC · re: Jeff King · lore

Re: [BUG] git-svn fails to rename files with %20 in filename

On Mon, 2011-02-21 at 07:31 -0500, Jeff King wrote:
Show 39 quoted lines
> On Mon, Feb 21, 2011 at 10:12:24AM +0000, Will Palmer wrote:
> 
> > Someone accidentally checked some files containing "%20" in their names
> > into our svn repository, which is accessed with either svn or git-svn
> > depending on the developer.
> > When I attempted to correct this by renaming the file, I received (on
> > dcommit):
> > Filesystem has no item: File not found: revision 1, path
> > '/theBeginningOfTheOriginalFileName theRestOfTheOriginalFilename'
> > at /home/wpalmer/libexec/git-core/git-svn line 576
> > 
> > A recipe for reproducing this bug is as follows:
> > [...]
> 
> Thanks for the thorough test case. It seems to pass for me if with this
> applied:
> 
> diff --git a/git-svn.perl b/git-svn.perl
> index 177dd25..7daf63c 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -4556,9 +4556,7 @@ sub repo_path {
>  
>  sub url_path {
>  	my ($self, $path) = @_;
> -	if ($self->{url} =~ m#^https?://#) {
> -		$path =~ s!([^~a-zA-Z0-9_./-])!uc sprintf("%%%02x",ord($1))!eg;
> -	}
> +	$path =~ s!([^~a-zA-Z0-9_./-])!uc sprintf("%%%02x",ord($1))!eg;
>  	$self->{url} . '/' . $self->repo_path($path);
>  }
>  
> 
> IOW, it looks like the path we hand to svn needs url-encoding even for
> the local case (which make sense, as it is a file:// url). But I know
> nothing about svn, so probably I am breaking some other weird non-url
> local case. :)
> 
> -Peff

Unless I've got my line-numbers mixed up, the commit which introduced the https-specific encoding behaviour, 29633bb91c git-svn: fix commiting renames over DAV with funky file names

seems to be of the opinion that the bug did not effect file:// and svn:// URLs. Has something changed?

Jeff King· Feb 23, 2011, 10:04 UTC · re: Will Palmer · lore

Re: [BUG] git-svn fails to rename files with %20 in filename

On Tue, Feb 22, 2011 at 04:50:15PM +0000, Will Palmer wrote:
Show 12 quoted lines
> > IOW, it looks like the path we hand to svn needs url-encoding even for
> > the local case (which make sense, as it is a file:// url). But I know
> > nothing about svn, so probably I am breaking some other weird non-url
> > local case. :)
> > 
> 
> Unless I've got my line-numbers mixed up, the commit which introduced
> the https-specific encoding behaviour,
> 29633bb91c git-svn: fix commiting renames over DAV with funky file names
> 
> seems to be of the opinion that the bug did not effect file:// and
> svn:// URLs. Has something changed?

Yeah, what we are seeing definitely contradicts that commit. It's been 3.5 years; maybe something was tweaked in the subversion library? I tried reading the code, but I got lost amidst all of the nasty perl bindings. I couldn't find anything relevant in svn's changelog or in google, either.

-Peff
Steven Scott· Mar 2, 2011, 15:27 UTC · re: Jeff King · lore

Re: [BUG] git-svn fails to rename files with %20 in filename

On Wed, Feb 23, 2011 at 5:04 AM, Jeff King <peff@peff.net> wrote:
Show 22 quoted lines
>
> On Tue, Feb 22, 2011 at 04:50:15PM +0000, Will Palmer wrote:
>
> > > IOW, it looks like the path we hand to svn needs url-encoding even for
> > > the local case (which make sense, as it is a file:// url). But I know
> > > nothing about svn, so probably I am breaking some other weird non-url
> > > local case. :)
> > >
> >
> > Unless I've got my line-numbers mixed up, the commit which introduced
> > the https-specific encoding behaviour,
> > 29633bb91c git-svn: fix commiting renames over DAV with funky file names
> >
> > seems to be of the opinion that the bug did not effect file:// and
> > svn:// URLs. Has something changed?
>
> Yeah, what we are seeing definitely contradicts that commit. It's been
> 3.5 years; maybe something was tweaked in the subversion library? I
> tried reading the code, but I got lost amidst all of the nasty perl
> bindings. I couldn't find anything relevant in svn's changelog or in
> google, either.
>

In my case, I *was* using http://, and applying that patch (to remove the HTTP check) didn't work. Same error as earlier in the thread. I thought it worked once, but I eventually saw it fail again. git-svn is definitely broken if the URL has a %20 in it, and it's quite useless when you never know when you'll be unable to dcommit and manually have to generate patches and apply them to a svn repository.

Thankfully I got my team to switch to git, so best of luck to the rest of you trying to use git-svn when a doofus put a space in the URL :)

-- Steven Scott

Steven Scott· Feb 21, 2011, 15:26 UTC · re: Will Palmer · lore

Re: [BUG] git-svn fails to rename files with %20 in filename

On Mon, Feb 21, 2011 at 5:12 AM, Will Palmer <wmpalmer@gmail.com> wrote:
Show 8 quoted lines
> Someone accidentally checked some files containing "%20" in their names
> into our svn repository, which is accessed with either svn or git-svn
> depending on the developer.
> When I attempted to correct this by renaming the file, I received (on
> dcommit):
> Filesystem has no item: File not found: revision 1, path
> '/theBeginningOfTheOriginalFileName theRestOfTheOriginalFilename'
> at /home/wpalmer/libexec/git-core/git-svn line 576

This is the same issue I've been seeing (except that the %20 is in a parent directory on the SVN server). It makes using git-svn fraught with danger, since I never know when I'm going to be unable to checkin days' worth of git commits.

-- 
Steven Scott

← back to recent threads