What do you expect the api to canonicalize things like “h” or "” to?
We can’t make everything a valid url… That is simply impossible. You need to
pass something that at least looks like a url. The canonicalize api just
forcesany urls that point to the same location to use the same canonical
format. It can’t fix all user errors.
If a user passes junk to an api, it can expect junk.
In all these cases the api user can see that we will error on it by calling the
is canonical api itself. Catching these problems belongs in a different layer
than the canonicalize function that can’t even return an error message.
Note that in general changes to the url and dirent canonicalize rules require a
working copy format bump, so there is not that much that can change there,
unless we are certain all existing values remain valid… And this specific value
is valid on platforms where ‘:’ is valid in local paths.
Bert
Sent from Surface
From: 'Stefan Kueng'
Sent: Wednesday, June 10, 2015 10:22 PM
To: Bert Huijben, dev@subversion.apache.org
On 10.06.2015 21:04, Bert Huijben wrote:
> I don’t think we can really fix that url in the api by canonicalizing it
> to something completely different/unrelated, but the assertion makes it
> obvious that the caller can just see/check that the url is not going to
> work… just like values such as the empty string or strings with no
> scheme, that can't be canonicalized to a url either.
Such a behavior might be ok for a command line client.
But as you can see from the original report, other clients either need
proper error messages or a canonicalize API that does what its name says
it does.
As it is now, the svn_uri_is_canonical() and the
svn_dirent_canonicalize()/svn_uri_canonicalize() don't really match.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest interface to (Sub)version control
/_/ \_\ http://tortoisesvn.net
