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

Re: relative URLs (was: rapidsvn feedback)

From: Dave Cridland <dave_at_cridland.net>
Date: 2002-08-02 10:57:41 CEST

On Thu, 2002-08-01 at 22:24, Greg Stein wrote:
> IMO, we shouldn't use "%%" in any situation (although I could bend for the
> cmdline). That form just isn't a standard URL.
> When you have a GUI, where there is no ambiguity about what was typed in,
> then you allow users to enter a relative URL, and use the standard URL
> composition guidelines to establish the absolute URL. The only tricky part
> is decided what the "base" is for the relative URL to be useful. The RFC
> actually covers some of how to defined a base URL.

This thread is now officially confusing me. Admittedly this doesn't
usually take much - a piece of paper with "Please Turn Over" written on
both sides usually does the trick.

What's the difference between...

(base URL of directory: http://svn.somewhere.tld/repos/dir)

[user@host dir]$ svn cp file1.c file2.c


[user_at_host dir]$ svn cp http://svn.somewhere.tld/repos/dir/file1.c

...and other combinations of URL and file.

I'm unclear what difference there is, if any. Similarly with other
commands. The sole difference I can see is that for some commands, there
is no need to touch the repository when all arguments are a local file,
but surely this is largely a matter of being slightly smarter?

I can also see that things get more complex in terms of figuring out the
base URL of mixed working dirs, done with, say, `svn switch' (which
isn't in the man page, in case nobody's noticed.).

Perhaps a --base-url-from=<dir> switch could be used to clear up

I appreciate I'm probably missing something fairly crucial here, so feel
free to treat me like an idiot. :-)


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 2 10:55:37 2002

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.