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

Re: svn status proposal

From: Greg Stein <gstein_at_lyra.org>
Date: 2001-09-14 22:18:09 CEST

On Fri, Sep 14, 2001 at 09:40:49AM -0500, Ben Collins-Sussman wrote:
>...
> The only change being proposed is to add the square brackets;
> everything else is already there and working:
>
> XXX ## [ ##] ( ##) path
>
> The XXX represents local mods: {M,C,A,D,R,_} in the first two
> positions (one for text, one for props.) The 3rd X occasionally
> displays an L to indicate working copy is locked.
>
> The ## is the working revision.
> The [ ##] is the last revision to have changed (server query).
> The ( ##) is the head revision (server query).

Why we are revamping this stuff, I'd prefer if we just tossed the brackets
and parentheses. Just think of the hell to quote those things in a regex to
parse our output. The brackets add nothing.

And I'm in favor of a simpler output. And don't mention "habituation", or
I'll have to say that my habit says:

$ svn status

produces

M foo.c

and

$ svn status -u

produces

M 58 102 102 foo.c

Both are equally valid habits.

>...
> * proposal
>
> svn status : case 1
> svn status -u (--update) : case 3
> svn status -v (--verbose) : case 2
> svn status -v -u : case 4

Agreed.

>...
> I know that in case 1, some people would really like to see the
> revision fields go; but I feel strongly about *not* changing
> the way status lines look based on switches.

Why? Your expectations of results are based on the switches you use. As
somebody mentioned, think "ls". Or think -v in this case: in one case you
get only modified stuff, and in the other you get it all.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:41 2006

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.