Greg Stein <gstein@lyra.org> writes:
> Like Joe, I'll patch my client to give me the short format. And I'll post
> the patch to the list so that others, like Joe and Branko and Mo, can apply
> that patch and use it.
>
> If out of some twisted sense of consistency, you don't want it applied to
> the repository, then it will just live on as a patch. A commonly-applied
> patch, I bet, but it will exist.
>
> The short format gives you the information that you need and does not
> clutter your brain with irrelevant stuff. Go look in the UI book that you
> referred to. The typical usage is "what was modified". And the short format
> answers that question succinctly.
Yes, the entire question revolves around what is "relevant". I think
the local rev is usually useful (and not much of a distraction when it
isn't), you don't think it's usually useful (and is a distraction).
There is no need to keep two competing patches around permanently,
however; we can just vote on it :-). At this point, I think that is
the best solution, since all other aspects of `status' have been
resolved to everyone's satisfaction, and this is after all about
satisfying the majority of users in terms of the information they get
from `status'. (I.e., sometimes voting really is the best way to make
a decision.)
The question is:
Should all status output show the same (or very similar format),
that is, always including the local revision number? Or should the
default not show the local rev, and you get the rev when you invoke
st --verbose, which also happens to list all entries?
[ ] Yes, always include the local rev.
[ ] No, the local rev is usually a distraction, please show it
only with --verbose.
I don't see any point confining this vote to committers only, as it's
a UI issue not a technical implementation issue; I hope it's all right
with all the committers if we just accept votes from anyone who
happens to be subscribed to this list right now (?).
Post votes to the list, please. :-)
-K
---------------------------------------------------------------------
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:42 2006