[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn status proposal

From: <kfogel_at_collab.net>
Date: 2001-09-21 00:06:33 CEST

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.