[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: Shurik O <shuriko_at_gmail.com>
Date: 2005-01-25 21:48:55 CET

>> 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.

How about a repository that is accessed using svn:// (svnserve -r) or http:// from the inside and
svn+ssh:// from the outside?

The latter's repository path is very likely to be different from that of the former.

Brian W. Fitzpatrick wrote on 01/25/2005 9:36 AM:
>
> 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.
>
>>>> 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.
>
> 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.
>
> -Fitz

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 25 21:50:28 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.