Philip Martin <phi...@codematters.co.uk> writes: > Consider > > svnadmin create repo > svnmucc -mm propset svn:externals 'foo://bar::/ X' '' > svn co file://`pwd`/repo wc > > 1.8 gives a warning on checkout: > > svn: warning: W170000: Illegal repository URL 'foo://bar::' > > but 1.9 gives a SEGV: > > svn: ../src/subversion/libsvn_subr/dirent_uri.c:1529: uri_skip_ancestor: > Assertion `svn_uri_is_canonical(child_uri, NULL)' failed.
The difference is simple: both 1.8 and 1.9 call svn_uri_canonicalize() and get the same output, but 1.8 calls apr_uri_parse() before calling any svn_uri_ functions, while 1.9 calls an svn_uri_ function before apr_uri_parse(). > These strings returned by svn_uri_canonicalize() fail > svn_uri_is_canonical(): > > foo://bar:: > foo://bar:123x > foo://bar:- > > How should strings like this be handled? There is a difference between a canonical URL and a valid (or "legal") URL. While svn_uri_canonicalize() could modify some of the above to be valid it is not reasonable to change all invalid URLs into valid ones, there is no good rule we could follow. It also seems unreasonable to treat such URLs as paths rather than URLs. svn_uri_canonicalize() has to output an URL that can be passed to the other svn_uri_ functions, but it doesn't have to be a valid URL. When our top level code allows a canonical but invalid URL through that is OK, when we reach the point of attempting to use the URL and discover that it is invalid we can return an error. -- Philip
