Julian Foad wrote:
> 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
> )
No, that's not right.
We are in the cvs2svn repository, and go up one level out of it, and then
into the svn repository.
>> 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?
Dir-rel is utterly useless for this case, since "trunk", and
"{branches,tags}/foo" have different depth.
Building knowledge of the site-to-repository-root path into the externals is
non-ideal.
It's just slightly better than the current situation. Since we are reworking
externals anyway, we should do the best we can do.
I imagine ///tags/FOO/somemodule being a very common kind of external.
Think of any module which wishes to import known-good versions of other
modules in the same repository.
>> 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.
But, I was assigning a meaning local to subversion - so who is there to
conflict with?
> 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?
Demonstrated above.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 24 23:54:16 2005