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

Re: [PATCH] Issue #3108: "svn changelist clname" does nothin

From: David Glasser <glasser_at_davidglasser.net>
Date: Wed, 27 Feb 2008 09:31:11 -0800

On Wed, Feb 27, 2008 at 9:14 AM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> Daniel Shahaf wrote:
> > David Glasser wrote on Tue, 26 Feb 2008 at 15:34 -0800:
>
> >> On Tue, Feb 26, 2008 at 3:16 PM, Daniel Shahaf wrote:
> >>> David Glasser wrote on Tue, 26 Feb 2008 at 13:10 -0800:
> >>> > Hmm. I kind of feel like "svn changelist" should default to
> >>> > svn_depth_infinite rather than svn_depth_empty. Then (a) "svn cl new
> >>> > --cl old" lets you do a rename, without need an extra "-R"
> [...]
>
> >>> > and (b)
> >>> > "svn cl clname directory" will add the directory's recursive contents
> >>> > to clname instead of just doing *nothing*.
> [...]
>
> > Do you think the directory should be given explicitly in this usage?
> > Otherwise, plain 'svn cl NAME' would recursively remove all files in the
> > current directory from their changelists.
>
> A TARGET argument should be required in all commands except where an implicit
> "." is demonstrably useful enough to be worth the saving of only two characters
> of typing, and where it's a safe default. (Unfortunately, I think some svn
> commands already assume an implicit "." where it's not very useful.)
>
> I recommend the "changelist" command not assume an implicit "." ever, which is
> in accordance with its current help text but against its current implementation
> (trunk_at_29608M).

+1

--dave

-- 
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-27 18:31:23 CET

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.