[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: [bug?] perl bindings: SVN::Ra->new trips assertion when file:// URL contains a space

From: Bert Huijben <bert_at_qqmail.nl>
Date: Sat, 17 Dec 2011 09:11:59 +0100

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.