[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Relative Externals - format debate

From: David Wilson <dw_at_botanicus.net>
Date: 2005-01-03 19:59:57 CET

Max Bowsher wrote:

> 4. Scheme-relative externals.
>
> Consider a related grouping of repositories, maybe even on different
> hosts, which may be accessed either as http:// or https:// - but, if
> you are accessing one one way, you probably would rather use the same
> protocol for externals too.
>
> e.g. "myexternal httpsame://svn2.example.com/repos/beta/foo"
>
> Let the brainstorming begin! :-)

I can't ascertain if this matches any of your above descriptions
(although possibly the one quoted is similar), but how about
URL-relative externals? Let the syntax be (regexy):

    Absolute URL [act like svn 1.1]: ^[a-z0-9]+ [...]
    Relative URL: ^[./] .+ [...]

On absolute URL, libsvn_wc works as it presently does. On relative URL,
make a duplicate copy of the URL for the current directory. For each
"../" encountered, remove one URL part from the end of the duplicate
URL. For each non-"../" encountered, append it.

I think this is more or less the same way as relative URLs work on the
web (although I haven't read up on it).

I'm sure this has been discussed already, I'll reiterate just in case:
this would allow for example, a whole svn server to change protocol
without having to rewrite externals, or a dual-protocol SVN server to
have protocol-agnostic svn:externals definitions.

The scheme above would also be unsurprising, for example, for a web
developer who is just starting out using Subversion.

David.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 3 20:42:31 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.