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

Re: [RFC] Paths API (svn_dirent_uri.h) - improvements

From: Greg Stein <gstein_at_gmail.com>
Date: Thu, 12 Nov 2009 12:02:45 -0500

On Thu, Nov 12, 2009 at 09:57, Julian Foad <julian.foad_at_wandisco.com> wrote:
>...
>> The intent is that a relpath is always attached to some root. For
>> Windows that could be "\". For a URL, that could be
>> "http://hostname/". Whatever. But never ever a leading slash.
>
> I hope we're in agreement that a relpath can not only be relative to
> that kind of minimal "root", but can also be relative to a repository
> root such as "http://hostname/dir1/dir2/" or to a WC absdir such as
> "/home/julian/wc" or to another relpath such as "subversion/libsvn_wc",
> in fact relative to any URI or dirent or relpath.

Yup. A relpath can be joined onto any of the three.

>...
>>  As I noted above, we also want them to *always* be
>> absolute. The codebase is pretty darned close to allowing for that.
>> Also note that the svn_uri_* functions are new in 1.7, so we can
>> define them with this restriction.
>
> You explained in follow-up emails that it's useful to be sure that we're
> always using abs URIs in these APIs. That's an OK position to take, and

Another thing that I just thought of: a relative URI is not useful.
You always have to join it with something. By taking the position of
"always absolute", then it is "always useful" and you don't have to
search your context for something to join it with.

> I'm not against it, but if we do that then I'm sure we will also need a
> few API functions to handle relative URIs. That's fine, and may be the

Yup.

>...

Cheers,
-g

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2417145
Received on 2009-11-12 18:03:05 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.