On Thu, Sep 20, 2001 at 05:06:33PM -0500, kfogel@collab.net wrote:
> Okay, have caught up on the "svn status" thread too now. A lot of
> issues were helpfully clarified, but obviously not settled. So here
> is a proposal for status's behavior, trying to balance all the
> concerns while avoiding the design-by-committee effect. :-)
>
> 1. Let's please have one consistent format for status output, so
> users can habituate.
No. That is based on a faulty premise. You are assuming that the user
perceives these two commands to be identical, thus requiring the same
output:
$ svn status
$ svn status --verbose
I certainly don't see them to be the same, nor would I expect them to be.
The perfect analogy is the following:
$ ls
$ ls -l
The output is dramatically different, but I'm "habituated" to that
difference because the two ls commands are *different* to me.
>...
> a. I'm aware that having it be asterisk-vs-nothingness
> instead of asterisk-vs-underscore violates the principle
> of always having a placeholder, so parsers can count on
> whitespace as a delimiter. However, the visual
> improvement of having emptiness instead of an underscore
> in that third column is so great that I think it's worth
> violating this principle. The output is fixed-width
> anyway, so parsers can get where they're going that way
> (also, the next column is always a number, so that's
> another way to parse reliably).
The suggestion that Ben presented had a fixed set of columns for each of the
different invocations of svn status. So this isn't really an obvious benefit
to your proposal.
>...
> distinguish between text mods and prop mods. But is the
> extra complexity really worth it, when compared with the
> stark expressive power of a single naked asterisk? Nah.
> Let's go with simplicity. :-)
Agreed.
> 2. We all seemed to agree that status should not list all entries
> unless explicitly requested to. That's cool. But there was
> still discussion about whether default status should show only
> locally modified files, or locally modified files plus
> out-of-date files.
>
> I'd like to register a strong vote in favor of the latter. I
> realize this is a matter of taste, but this way feels a lot more
> intuitive to me. We're asking about the status of the file.
> That status can include out-of-dateness as easily as
> modifiedness. Let's use "svn status -M" to restrict it to
> locally modified files, and have default status show *both*
> kinds of modifications: local and repository.
IMO, the usage pattern of svn status disagrees with you. Out-of-dateness is
rarely used. How often do you care whether something is out of date?
Typically, you just go and update your WC. The more typical usage is to find
what you've been working on and figure out what chunks are to be committed
as a group.
On the occasion where you need more information, then you have a switch to
retrieve that information.
Further, the default to avoid the network is a very powerful benefit, much
like our diffs can avoid the network. For the default to give you your
typical information and to do it quickly... that is great.
> 3. There is a -M switch, meaning "show only locally modified
> files". Since the user has indicated that they're really only
> trying to find out about local mods, this switch causes status
> to avoid contacting the repository at all (see point 5).
That switch was introduced because it gave people a way to produce the
status that they *really* wanted. Effectively, it is a patch over the
erroneous initial behavior of svn status.
Its current presence does not mean it is the correct thing. It was
introduced on a faulty base :-)
> 4. There is a switch meaning "show all entries"; mostly you'd use
> it to see what's under revision control, and to see revision
> numbers for everything. This switch can be used in combination
> with --no-repos (see point 5), but not with -M, since it
> directly contradicts -M.
This would be the --verbose switch.
> 3. There is a "don't contact the repository" switch, call it
> `--no-repos' for now. The output either doesn't show the head
> revision at all, or shows it as a question mark. It also
> doesn't attempt to show what is out-of-date. I hope it's clear
> why this switch is separate from the -M switch -- it's because
> one might want to see local info about all entries while still
> not going over the network.
I think the preference is to avoid the network in the default case, and to
explicitly request network-based information.
> I know this all seems complex when described formally, but in actual
It is more complex than Ben's proposal, and it doesn't fit the typical usage
pattern very well.
> usage it is quite simple,
No. You have introduced the -M, --verbose, and --no-repos switches. *Three*
Ben's proposal had two: --verbose and --update. The former implies the
latter, so you'd never really need to combine them (unlike yours).
> because the output format never changes, and
That is a false benefit, as I described earlier.
> the two most commonly desired behaviors are those achieved with the
> default, and with -M.
The most common is the -M form, with a short output. The second is the
--update switch, as presented in Ben's summary. You have your switches
backwards from (IMO) typical usage.
> The rest is stuff a user learns if and when
> they need it, and it won't get in their way before then.
Not a good rationale. Users can learn anything. The real question is to
match the commands/switches to typical usage.
> Note that there's no "--verbose" switch. That switch was a
> combination of two separate things: whether or not to show all
> entries, and whether or not to talk the repository. There's no reason
> to connect those two things, and I can think of circumstances where
> one might want either one but not the other.
They can be disjoint -- you could make a person provide both --verbose and
--update, but that is going to be even more confusing. Let's say that
--update does not imply verbose; you'll get output that looks like of like:
_ * 57 60 foo.c
M 55 62 bar.c
_ * 59 60 baz.h
_ * 59 61 burm.c
Head: 62
In the above output, you have some not-locally-modified entries, but you
don't have them all (as --verbose would normally give you). So now you've
truly confused the user... where are the other files?
> Thoughts?
Yes. :-)
Ben had an excellent proposal. It fit typical usage, it had good output
formats, it was very easy to understand, it didn't introduce a lot of
switches, etc etc etc.
Cheers,
-g
--
Greg Stein, http://www.lyra.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