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

Re: Finishing relative svn:externals

From: Blair Zajac <blair_at_orcaware.com>
Date: 2007-07-20 05:41:59 CEST

Vlad Georgescu wrote:
> Blair Zajac wrote:
>> Proposal
>> ========
>> 1) Be as RFC 3986 compliant as we can.
>> 2) The relative URLs are:
>> relative to current directory
>> ../../branches/1.4.x
> Since r23746 we support both "URL TARGET_DIR" and "TARGET_DIR URL" in
> externals definitions, so using relative paths for URLs might be ambiguous.

We could only support the new relative URLs in the new "URL TARGET_DIR",
or make the "-r N" mandatory in the new scheme to disambiguate them.

>> relative to repository root
>> ^branches/1.4.x
> This is somewhat bikesheddy, but I'd very much prefer '//' to '^' for
> this purpose, for at least three reasons:
> 1) ^ is not really a forbidden character in paths, so again, there's
> potential for ambiguity

True, but using ^ at the front of a path is very rare.

> 2) // is easier to type and feels less 'magic'; this is important if we
> are going to use the same syntax on the command line

But this has known meaning for the RFC.

> 3) there are already people building wrappers around svn with exactly
> this syntax: http://code.google.com/p/gvn/
>> relative to server root
>> /svn/repos/branches/1.4.x

Well, svk has a different meaning for //, so that gvn uses it doesn't
mean another one has to.

> Do we really need this? We can refer to paths in the same repository
> using the syntax above, and to paths in other repositories on the same
> server using //../some_other_project/foo/bar (since repositories usually
> have a common parent path).
>> relative to scheme
>> //svn.collab.net/svn/repos/branches/1.4.x
> I guess I don't really see the point for this one either.

For completeness :)


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 20 05:41:24 2007

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.