Okay, sorry Joe, Ben explained to me what you meant. I now understand:
There's also been a proposal for a status output format that shows
_no_ revision numbers, just modified-ness, for example,
$ svn st
M foo.c
M qux.c
- bar.c
- blah.h
- bazzam.txt
M etc.h
$
Or something similar. And you (correct me if I'm wrong) favor that
format, as opposed to one that always shows the local revision number.
Apologies for jumping on you. I had mistakenly thought there was a
general consensus that showing the local revision number is a Good
Thing, but now I am reminded that there isn't such a consensus.
This makes clear the growing disparity between the formats, too. If
we only include the local revision number when --verbose is used, then
the two formats really are growing apart, necessarily.
Okay. So:
I do think it's better to always include the local revision number,
even though admittedly you (and probably others) don't need it in your
most common use case. Here's why:
If default status does _not_ show the local rev, then we are forced to
choose one of these two alternatives:
1. Have a separate switch for showing local rev. Of course, when
this switch is in effect, the output format will change
noticeably.
2. Make local rev show up only when one passes `--verbose' (i.e.,
when the network is used). And of course, the output format
still can't be very similar to the default.
(2) is a very bad option, because it associates querying the local
revision with connecting to the repository. These should be
independent. There are many circumstances where one might want to
find out the local rev without also attempting a network connection.
I doubt anyone would argue for option (2).
But (1) is not good either, because it adds Yet Another Switch. By
tolerating one column of sometimes-unwanted information, we can lose
that switch and keep the invocation interface that much simpler.
So it's not so much that I think having the local rev number always
there is a Good Thing, as that not having it seems to inevitably
result in one or another Bad Thing.
Thoughts?,
-K
P.S. I know it may seem strange to some to be devoting this much
energy to an output format question when we have other pressing needs,
such as more deltification work. But the `status' command is going to
be used a lot more with Subversion than with CVS -- perhaps will be
the most frequently used command -- so I think it's worth the time.
kfogel@collab.net writes:
> Joe Orton <joe@manyfish.co.uk> writes:
> > I'd rather have to kick you once a year because 'svn st -v' is not
> > consistent with 'svn st', than have to kick you twenty times a day
> > because 'svn st' has got confusing output with lots of weird asterisks
> > and numbers which I don't want to know about.
>
> Wait a minute here, Joe. You're way exaggerating.
>
> We're not talking about "lots of weird asterisks and numbers". We're
> talking about *one* extra column which shows up *only* when the user
> asks for it, and does not clutter the visual field when not asked for.
>
> This column potentially contains an asterisk (or whatever), or else
> nothing. There are no extra numbers at all in my proposal. You will
> not kick anyone twenty times a day, because you won't see it twenty
> times a day, assuming that you usually use the default status command.
>
> > I think it'll be a great shame if you make plain 'st' have the chatty
> > output just to be consistent with the other commands.
>
> Huh?? What, specifically, is the chattiness you're referring to? Can
> you give a specific example of an output that would be chattier than
> necessary?
>
> There is no visible difference between the proposals as far as plain
> status output goes. There is *no* extra chattiness. Put them
> side-by-side and see for yourself: default status has no extra visual
> clutter in my proposal than in any of the other proposals.
>
> Honestly, I'm somewhat confused here. I believe I proposed an almost
> quantifiably minimally cluttered interface (see Jeff Raskin's "The
> Humane Interface"), that has no extra clutter... And people are
> objecting to some weird straw man, to something I've never proposed
> and never wanted.
>
> Please go back and look at the actual format examples I gave. I just
> can't figure out what part of that output could be removed without
> losing information.
>
> -Karl
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.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:42 2006