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

Re: alias 'svn up -n' to 'svn st -u' when '--nonrecursive' removed? :-)

From: Martin Pool <mbp_at_samba.org>
Date: 2002-07-16 04:09:08 CEST

On 12 Jul 2002, Karl Fogel <kfogel@newton.ch.collab.net> wrote:
> Eric Gillespie <epg@pretzelnet.org> writes:
> > I disagree. -n is fairly standard for "no-op". Lots of commands
> > use -n for "pretend you would do this", including ancient programs
> > like make and sh. I didn't know until reading this thread that
> > svn used something else for -n. I think that's a bad idea.
>
> Oh! I never noticed this pattern in other commands before. I only
> knew about it in CVS.
>
> Let's gather some more data from others on the list, since either one
> of us (or both) could simply be trapped in his own idiolect here.

rsync has -n, and it expands to --dry-run, which is one popular long
option, along with --no-act. Make is the same. (I think that may be
standard, rather than a gnuism.)

The GNU Standards for command-line behaviour mention this, but also
many other meanings for -n.

While we're in WIBNI mode, I think it would be nice if there were a
--verbose mode that makes the program emit some kind of trace of what
it was doing: connecting to the server, calculating diffs, ... I
suppose just whatever information would help with tracking down a bug,
short of actually attaching gdb to the thing. It would give people a
place to start if the program is hanging or not doing what they
expect.

I realize "svn stat" already has -v, but it really just provides a
more detailed display, rather than a trace as such.

-- 
Martin 
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 16 04:09:11 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.