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

Re: Final(?) Relative Externals format

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2005-01-24 22:55:18 CET

Max Bowsher wrote:
> Existing absolute external:
> http://svn.collab.net/repos/svn/trunk/subversion/tests/clients/cmdline/svntest

> Relative form 3: Repository-relative
> ///../svn/trunk/subversion/tests/clients/cmdline/svntest

(Actually, to make this example realistic, I think "repos/svn" is the path to
the repository, so this should be:

///../trunk/subversion/tests/clients/cmdline/svntest
)

> The concept of a repository within the URL is fairly unique to
> Subversion, and hence no suitable syntax is expressed in RFC 2396. This

I agree that repository-relative URLs seem like a good thing to have. However,
perhaps the need is not quite so strong.

The use of a repository-relative URL is in accessing a sibling project, or a
different tag/branch/trunk of the same project, within the same repository.
Compared with a directory-relative URL, you gain by not having to know how many
directories to go up (from where you are currently), but you may lose by
needing to know the full in-repository path to the external directory.
Compared with a site-relative URL, you gain by not having to know the path to
the repository, but often the site administrator will make that path short and
relatively stable anyway.

Using the example, what information do we need to know (and hope will remain
stable) to make the different kinds of reference?

   repos-rel: "/trunk/subversion/tests/clients/cmdline/svntest"
     vs.
   site-rel: "/repos/svn/" as well.

   repos-rel: "/trunk/subversion/tests/clients/cmdline/svntest"
     vs.
   dir-rel: the in-repo path of where we are now (or at least the depth of
it), instead.

I believe this indicates that the advantage of adding repository-relative URLs
to the other types is slim, because I can't see why the path-to-repo is much
more likely to change than the path-within-repo. Am I missing some significant
use cases in which the elimination of path-to-repo confers a great advantage?

> form takes advantage of the fact that whilst the RFC explicitly
> specifies the meaning of a relative URL beginning with zero, one, or two
> slashes, it is silent on the matter of three or more slashes.
> Therefore I feel this is a good way to accomodate this very useful form
> of relativity into an unused (and unlikely to be used) void in the URI
> standard.

Bad assumption ("Therefore"). If you think you can so easily assign your own
meaning to three slashes, don't you think other people are, even now, assigning
their own meanings? Down this path lies a likelihood of conflicts.

Apart from that, it looks good. How about proceeding with the other types of
relative URL, and leaving repository-relative out until a pressing need for it
is demonstrated?

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 24 22:57:17 2005

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.