[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: Brian W. Fitzpatrick <fitz_at_collab.net>
Date: 2005-01-25 18:36:41 CET

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.


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