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
--
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