> -----Original Message-----
> From: Jonathan Nieder [mailto:jrnieder_at_gmail.com]
> Sent: zaterdag 17 december 2011 7:59
> To: dev_at_subversion.apache.org
> Subject: [bug?] perl bindings: SVN::Ra->new trips assertion when file://
URL
> contains a space
>
> Hi,
>
> I have created a repository at '/tmp/test repository'. The following
> simple program:
>
> use SVN::Ra;
> my $handle = SVN::Ra->new('file:///tmp/test repository');
>
> produces the following result:
>
> svn: E235000: In file
> '/home/jrn/src/subversion/subversion/libsvn_subr/dirent_uri.c' line 2290:
> assertion failed (svn_uri_is_canonical(url, pool))
> Aborted (core dumped)
>
> I would have expected the constructor either (a) to DWIM and succeed
> (as it did with Subversion 1.6.x) or (b) to error out by throwing an
> exception with "die" that I can catch with "eval".
>
> I am guessing this assertion was introduced in r957893 (Move the
> knowledge on how file:/// urls are handled out of libsvn_ra_local,
> 2010-06-25).
Urls should never have supported unescaped spaces, but before Subversion 1.7
we didn't really check this and usually did what you would have expected. In
Subversion 1.7 arguments that were always documented to be canonical urls
are now verified to be really canonical in a number of places. (This checks
a lot more than just this simple example: for every character it must be
escaped or not escaped for the url to be canonical).
I think SVN::Ra->new() should have escaped this argument for you by
canonicalizing the argument before passing the value into the core library.
The reason we implemented this change is that before Subversion 1.7
file:///tmp/test repository and file:///tmp/test%20repository would have
been seen as different repositories, while they really should have been
handled as the same repository. (The problem for local paths was even
bigger, especially on systems with more path formats)
Bert
>
> I haven't yet looked into working around the behavior change in the
> application (and hence which behavior would be more appropriate) yet,
> but in any event being able to get a core dump so easily with the perl
> bindings feels like a bug, so I thought you might like to know.
> Thoughts welcome. Would behavior (a) or (b) be preferred?
>
> Compare [1], which discusses this behavior from the point of view of
> the user rather than how the bindings could be improved.
>
> Thanks,
> Jonathan
>
> [1] http://thread.gmane.org/gmane.comp.version-
> control.subversion.devel/132227/focus=132228
Received on 2011-12-17 09:13:12 CET