Max Bowsher wrote:
> 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.
Oops - sorry. I don't know where the cvs2svn repository is, and I completely
mis-read that example. To be clear now, I've found it as a sibling of "svn" at:
http://svn.collab.net/repos/cvs2svn/
> We are in the cvs2svn repository, and go up one level out of it, and
> then into the svn repository.
Oh. I would strongly advise against allowing that usage. That means that your
example relative URL contains part of the path-to-other-repos. Why is that
better than having the whole path-to-other-repos (apart from saving a few
characters)? Yes, it would mean that the site administrator can then move that
group of repositories, say from "/repos/{svn,cvs2svn}" to
"repos/new/{svn,cvs2svn}", but not to "/{svn,cvs2svn}" (unless your ".."
implementation is very bizarre) nor rename them to "/repos/{new-svn,...}".
I see that you were thinking of the repos-relative URL as being a dir-relative
URL whose starting point is the path to the repository root. With a
dir-relative URL you expect to be able to go backwards from its starting point
with "..", but I feel that a repository-relative URL should mean "within the
repository" just as a site-relative one means "within the site" and doesn't
allow you to go relatively from "//tigris.org/" to "/../collab.net/path/".
>> 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.
Sorry for the confusion. I was using the destination path from your example
without assuming any particular source path, and trying to make general
statements about how the various relative references would work. I agree that
dir-rel is no good for your particular example. The comparison in that case is
between repos-rel and site-rel.
> Building knowledge of the site-to-repository-root path into the
> externals is non-ideal.
Agreed, in the cases where that knowledge is unnecessary, i.e. for references
within a single repository.
> 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.
Yes. That use case is good. It would be very nice to have a syntax for those
in-repository references. It would be a bit nicer still if the syntax were to
be brief, like the triple-slash idea is, to make it convenient for typing.
>>> 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?
Well, who knows? Take the example of SVK and the double-slash URLs, and
imagine he'd chosen triple-slash.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 25 00:43:32 2005