[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: Branko Èibej <brane_at_xbc.nu>
Date: 2001-09-24 20:20:00 CEST

kfogel@collab.net wrote:

>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.
>

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.

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.

What I /haven't/ yet seen in this discussion is a good argument
/against/ havng a short format, except "consistency".
"A foolish consistency is the hobgoblin of little minds." --Emerson
:-)

-- 
Brane �ibej   <brane_at_xbc.nu>            http://www.xbc.nu/brane/
---------------------------------------------------------------------
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.