Brian W. Fitzpatrick wrote:
> On Jan 24, 2005, at 4:58 PM, Max Bowsher wrote:
>
>> Brian W. Fitzpatrick wrote:
>>> On Jan 24, 2005, at 12:18 PM, Max Bowsher wrote:
>>>
>>>> Relative form 3: Repository-relative
>>>> ///../svn/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 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.
>>>
>>> Ew. Given form 2, I think that this is unnecessary. -0.9
>>
>> Things doable with this form are also doable with form 2, but it
>> involves hardcoding the path-to-repository on the server into the
>> external. I.e., this doesn't fully solve the "repositories may move"
>> problem, just makes it a little less severe.
>
>> IMO, we really are overdue for some "repository root relative"
>> notation for use both on the command line, so it seems reasonable to
>> do it for externals too.
>>
>> Please clarify "Ew.".
>
> I just don't see the point in introducing this in addition to
> host-relative paths--how often does a repository move on a server? I
> mean really? I just don't think that the overhead of yet another
> relative form is a lesser evil than having to just deal with externals
> in a moved repository every 30 years when you move a repository on a
> server. Still -0.9 on this.
...
> I know I'm being a bit of a bastard here, but I just want us to think
> long and hard about each different relative scheme that we add as the
> more we add, the more confusion it's going to create for our
> (non-superhuman) users.
That's OK, I'm not offended - it would be a pretty boring discussion if
no-one ever made a counter-proposal! :-)
I'm still in favour of this, though.
I agree that everything that can be done with repository relative paths, can
be done with host-relative paths, but I view relying on that to avoid having
to design a repository relative path syntax as a bit of a kludge.
I'm a bit busy for the next few days, so I'm going to step back and take a
bit of time to form what I hope will be a cogent argument for including this
feature.
>>>> Relative form 4: Directory-relative
>>>> ../../svn/trunk/subversion/tests/clients/cmdline/svntest
>>>>
>>>> This form is compliant with RFC 2396.
>>>> It is stretching the example somewhat, since it would break on
>>>> tagging
>>>> or branching cvs2svn, since "tags/foo" and "branches/foo" contain a
>>>> different number of components to "trunk", but you should get the
>>>> idea
>>>> of what the syntax means, nonetheless.
>>>
>>> Seeing how fragile this is, esp. WRT tagging and branching, I'm also
>>> -0.9 on this.
>>
>> No, this is often requested. Without it, it's impossible to make links
>> within the scope of a single {trunk,tags,braches} set, and have them
>> work properly with branching and tagging.
>
> OK. I think I understand this schema better now and I'm fine with it.
Good, I think general consensus is that all 3 forms drawn from RFC2396 are
acceptable - so we can split the controversial repository relative
discussion off into a seperate discussion.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 25 20:05:29 2005