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

Re: Canonicalizing relative URLs

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Tue, 11 Jan 2011 22:07:12 -0500

On 01/11/2011 06:21 PM, Bert Huijben wrote:
>
>
>> -----Original Message----- From: C. Michael Pilato
>> [mailto:cmpilato_at_gmail.com] On Behalf Of C. Michael Pilato Sent:
>> dinsdag 11 januari 2011 22:16 To: Subversion Development Subject:
>> Canonicalizing relative URLs
>>
>> I'm looking at issue #3601, and am reworking the way that
>> svn_uri_canonicalize() behaves -- namely, I'm teaching it to normalize
>> the case of hex-digit pairs (of the "%AB" variety) for all URIs, not
>> just URLs. (Currently, it does this only for URIs with scheme data.)
>> But I find myself with a small problem: what to do about calls like
>> these in svn_wc_parse_externals_description3():
>
> Wait!
>
> The current intention is only to use svn_uri_*() for URLs. Relative paths
> should use svn_relpath_*(). So you are trying to fix a deprecated case.
>
> The remaining issue was that we still had the "/some/path" style paths,
> that aren't dirents, aren't relpaths and aren't urls. Julian fixed this
> with the svn_fspath__*() apis.

Okay. I'm cool with taking a different, more-future-thinking approach. But
I confess that I'm still not sure what approach is required in my situation.

What APIs do we use for "/repos/svn/!svn/ver/2/foo%20bar", which is a common
format of information used in WebDAV responses? It's not a full URL, not a
relpath, not a dirent, and not an fspath.

And back to my question about our relative URLs -- how do we handle the
likes of "^/foo%20bar" and "//server.com/foo%20bar"?

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
Received on 2011-01-12 04:07:54 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.