RE: svn status proposal

Hi,

I've been lurking for a while and have been following this discussion for a
little time. It seems that you have 2 requirements. The first is to a give a
simplistic listing of the files under version control

i.e.

M foo.c

and a separate requirement for people wanting to know assorted version
values of files.

i.e.

M 58 [ -] ( -) foo.c

I would suggest that you adopt the general unix philosophy that the defaults
should provide minimal but useful information and use flags to indicate that
you want more.

i.e. think of ls or ps

I think that's a strong argument to same running the command with no options
provides

M foo.c

If you want to see more information then use additional flags i.e. -l, -v

Pete

> -----Original Message-----
> From: Ben Collins-Sussman [mailto:sussman@collab.net]
> Sent: Friday, September 14, 2001 10:41 AM
> To: SVN Dev List
> Subject: svn status proposal
>
>
>
> I don't feel like this is such a bikeshed discussion anymore; people
> seem to be very worried about choosing bad UI defaults... they really
> want Subversion to get it Right, based on past annoying experiences
> with CVS's UI.
>
> So, I'm trying to detect a consensus. Here's my latest proposal,
> which takes into account the last several mails in this thread.
>
>
> * a "status line" always looks the same. This rewards habituation
> when visually parsing a line.
>
> 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).
>
>
> * use-cases:
>
> - users usually want to see only interesting lines
> - users only occasionally want to see all lines
>
> - users usually want to see local mods only (no network traffic)
> - users sometimes want to see local mods AND update
> info from repository
>
>
> See All Lines?
> No Yes
>
> See all info? No (1) (2)
>
> Yes (3) (4)
>
>
> * proposal
>
> svn status : case 1
> svn status -u (--update) : case 3
> svn status -v (--verbose) : case 2
> svn status -v -u : case 4
>
> The theory here is that case 1 is the most common use-case,
> and that case 4 is the least common use case. Cases 2 and 3
> are middle ground, so they each require a switch.
>
> In cases 1 and 2, where the network is not accessed, a status
> line would look like:
>
> M 58 [ -] ( -) foo.c
>
> In cases 3 and 4, where update info is fetched, a status line
> would have all the numbers filled in:
>
> M 58 [ 46] ( 60) foo.c
>
>
> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
>
> -
>

--
NOTICE:  The information contained in this electronic mail transmission is
intended by Convergys Corporation for the use of the named individual or
entity to which it is directed and may contain information that is
privileged or otherwise confidential.  If you have received this electronic
mail transmission in error, please delete it from your system without
copying or forwarding it, and notify the sender of the error by reply email
or by telephone (collect), so that the sender's address records can be
corrected.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org