On Mon, 2011-02-21 at 07:31 -0500, Jeff King wrote:
> 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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html