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

Re: rapidsvn feedback

From: Peter Davis <peter_at_pdavis.cx>
Date: 2002-08-01 17:05:02 CEST

On Thursday 01 August 2002 06:17, brane@xbc.nu wrote:
> Quoting Peter Davis <peter@pdavis.cx>:
> > On Thursday 01 August 2002 01:20, brane@xbc.nu wrote:
> > > svn switch %%/branches/issue-531-dev .
> > >
> > > and the client would grok from context that %% is
> > > http://svn.collab.net/repos/svn. That shouldn't be too hard to do
> >
> > today,
> >
> > Since switch only knows how to take URLs, why not just assume that an
> > absolute
> > path "/branches/..." is relative to the repository root, without
> > requiring the "%%"?.
>
> Becasue many commands accept either an URL or a working copy path, so there
> must be a way to distinguish the two. It would be slightly horrible if "svn
> cp" required the %%, but "svn switch" didn't. Consistency is always good.

I understand that %% would have to be required for the command line. But in
RapidSVN, it should be easy enough for you to label a field as a "URL", which
could imply that if you give an absolute path, the "%%" is implied (but not
disallowed, for consistency). RapidSVN should be able to be "smart" when it
can, whereas a "smart" command line client is just annoying.

> Oh, and if you have a directory named "%%" in your working copy, you can
> always refer to it as ./%%.

True.

Whether or not RapidSVN can be "smart" and not require the "%%" in certain
cases, I'd still be +10 on implementing this in both RapidSVN and the command
line, for *all* URL-based commands.

-- 
Peter Davis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 1 17:05:48 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.