[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: Sander Striker <striker_at_apache.org>
Date: 2001-09-14 17:37:49 CEST

> From: sussman@collab.net [mailto:sussman@collab.net]
> Sent: 14 September 2001 16:41

> 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.

Which is truly that, if you look at cvs status output.
 
> 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.

Hmmm, I think that if you compromise on that you have consensus. Maybe
display:

M 58 foo.c

in case 1? Or do people find that too much also?

On the rest I agree (with inclusion of the asterisk :).

Sander

---------------------------------------------------------------------
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.