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. This is crucial -- even with various
options modifying what information is actually presented, "svn
status" should still present it using a consistent template.
Otherwise humans will get confused. With that in mind, here is
a fairly simple format that is easy to parse visually, and has
places for the important information:
$ svn status
__ 17 foo.c
M_ 17 bar.c
__ 20 kremlin.h
M_ 17 st-basils.txt
__ * 17 images/irkutsk.jpg
__ * 17 images/tarbagatay.gif
__ 17 images/baikal.png
Head: 35
$
The first two columns are the familiar text-mods and prop-mods
columns, which people are already accustomed to. The next
column is the "up-to-dateness" column: an asterisk indicates
that the file has been somehow modified in the repository (text
and/or prop mods, or maybe deletion), or nothingness indicates
that an update would have no effect on that file.
The output ends with the head revision number, instead of
redundantly expressing the head in every column. :-)
A couple of comments:
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).
b. The asterisk could be "m" vs "d" instead, to indicate a
regular mod versus a deletion. Heck, it could also
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. :-)
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.
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).
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.
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 know this all seems complex when described formally, but in actual
usage it is quite simple, because the output format never changes, and
the two most commonly desired behaviors are those achieved with the
default, and with -M. The rest is stuff a user learns if and when
they need it, and it won't get in their way before then.
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.
Thoughts?
-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