On 1/10/06, Bart Robinson <lomew@pobox.com> wrote:
> I was thinking something like --explain/-x and the output would
> be something like, instead of
> M 965 wc/bars.c
> * 965 wc/foo.c
> A + 965 wc/qxxxx.c
> this
> wc/bars.c@965 (prop-mod)
> wc/foo.c@965 (updatable)
> wc/qxxxx.c@965 (added, w/hist)
This is really far too amusing. I think we're living in mirror universes.
Let me guess: are you a perforce user? Your suggested output format
looks a *lot* like the output of 'p4 open'.
The funny thing is, I was just complaining at work today about how
much I hated p4's output, particularly how hard it was to read. p4
puts the variable-length path as the first item in each line, thereby
effectively destroying all column alignment, and making it really hard
to parse. It doesn't use status codes, but full words to describe the
edits. I was moaning and wondering why on earth p4 doesn't create
nice neat little columns like 'svn status' does.
Since there's no accounting for taste, it's probably a waste of time
trying to persuade each other that one output format is more
"readable" than another. But: the main philosophy behind 'svn
status' is that the succinct codes and neatly aligned columns are
supposed to make it really easy for your eyes to parse the data and
get a quick overview. There are only 4 codes to memorize: M, A, D,
R. If you run 'svn status' constantly (like most of us do), then you
become really quick at instantly interpreting what you see.
I guess it boils down to one of those UI design debates: do you
design for the first-time user, or the experienced user? The
first-time user wants verbosity and hand-holding everywhere, whereas
those very things prove to be annoyances to experienced users.
Experienced users want everything to be as streamlined as possible.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 11 06:24:58 2006