[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: Max Bowsher <maxb_at_ukf.net>
Date: 2005-01-24 22:14:05 CET

André Malo wrote:
> * Max Bowsher wrote:
>
>> Hmm. I really don't like the concept of a scheme which actually isn't a
>> scheme, it's a modification applied to some other implied scheme.
>>
>> /// makes more sense to me.
>
> I tend to disagree. It represents a specific addressing scheme (of a
> subversion resource) independent from any physical access. A bit like
> mailto:.
>
> Further I don't consider /// as compliant, because there is no rule in RFC
> 2396, which defines a triple slash at the beginning -> it could be
> rejected
> by a strictly compliant URI parser.

Only subversion will ever have the ability to correctly interpret these
URL-like things, so I don't see the above as a problem.

RFC 2396 never envisaged something filling this role, so I don't see any
problem with exploiting syntax it left undefined to cater to our needs.

I don't view this as suitable for a scheme, because scheme: implies an
absolute URL, and this is not absolute. (A mailto: is absolute).

My reasons for favouring /// are that it is a short symbolic construction,
which fits in with the general theme of the other relativity specifiers: (
// / ../ )

Also, there is the possibility of re-using this to repair the extreme
verbosity of our command line interface, as compared with CVS's.

For example:

cvs up -r BRANCH
svn sw ///branches/BRANCH

Hence, I am seeking something small, visually-distinctive, that I can type
in under a second.

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 22:15:42 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.