Branko =?ISO-8859-2?Q?=C8ibej?= <brane@xbc.nu> writes:
> I think you got things upside down, Karl. What I think Greg and Joe
> proposed (and I agree with) is that there should be two formats: A
> simple one, with no revision numbers, that shows only local
> modifications, e.g.:
>
> M foo.c
> _C bar.c
> M_ baz.txt
>
>
> And a more verbose format (e.g., the one you proposed), that's switched
> on by the --verbose switch; --verbose should also list local files that
> aren't modified. However, --verbose should /not/ imply --update, it
> should be the other way around. Only --update touches the network, and
> --update implies --verbose: the rationale is that it really makes no
> sense to fetch status information from the server, then throw it away.
Ick. Please, no. :-)
Why should --update imply --verbose? I usually don't want it to, and
think the same is true for most people.
- The most common question is, what have I locally modified?
- The next most common question is, what local files are
out-of-date w.r.t. the repos?
- The least common question is, what is the status of every local
file, whether modified or not, whether out-of-date or not?
Either of the first two questions, or both of them together, is still
much more common than *any* combination which includes the third.
> So you get three use cases:
>
> 1. Show local modifications only: "svn st" (outputs in 2-column format)
> 2. Show the status of all version-controlled files in the WC: "svn st
> --verbose" (outputs in 4-column format)
> 3. Show status of WC and server, including the changes "svn up" would
> make: "svn st --update" (touches the network, implies --verbose).
>
>
> Joe's point is that (1) is by far the most often used form; and, from my
> own experience, I agree.
Sure. I agree too. But it's also very relevant that the long
listing, in which even files that are unmodified and up-to-date are
shown, is by far the *least* commonly needed, and therefore it should
not be linked with the up-to-date check.
In short, users need to be able to ask about modifications (either
local or repos-side) without the output being cluttered by zillions of
files that are not modified on either side.
> What I /haven't/ yet seen in this discussion is a good argument
> /against/ havng a short format, except "consistency".
The argument is that by having a short format, we will force the
existence of another switch in order to get the long format -- because
this switch cannot be the same as the switch that contacts the repos,
nor should it be the same as the switch that causes all entries to be
listed (after all, why should merely listing more entries also cause
the format of each line to change? It's as if ls -a also implied -l).
> "A foolish consistency is the hobgoblin of little minds." --Emerson
> :-)
Yes. But this is not a foolish consistency, it is a smart
consistency.
(Anyway, minds have the consistency of aged cottage cheese, or so I'm
told by med students.)
-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