Re: svn status proposal

On Sat, Sep 15, 2001 at 08:37:47PM -0500, Ben Collins-Sussman wrote:
> Mo DeJong <supermo@bayarea.net> writes:
>...
> > As far as the "don't contact the server" thing goes, I think contacting the
> > server should be the default. Passing a --update flag to the status command
> > seems very confusing. The () pairing might look like this if the server
> > could not be contacted.

I believe the "typical" case is "give me the status of my local files." The
secondary case is "what happens when I update?" The latter is not as common
because many people will simply do the update.

Given the common case is to request local file info, then we can do that
without the network. There are advantages to avoiding the network anyhow, so
it makes sense to do so.

"could not be contaced" could take a while to determine. Routing errors or
firewalls that simply drop SYN packets end up causing the client to take a
long time before a timeout occurs. Then there is the whole autodial thing,
etc etc. We can easily skip that for the common case, and defer it to when
somebody asks for the additional data.

>...
> Hmmm.... I sense a holy war coming. It seems like a lot of people
> *really* want the network "off" by default. I wonder if anyone
> besides Mo feels strongly the other way.

Urm. Bad term, there :-(

I believe we ought to simply vote on whether people feel the "uses" are
ordered as you listed them below. Assuming the order is correct, then I feel
you have specified the commands in the most useful fashion(*).

1) "svn status" for displaying local info
2) "svn status --update (-u)" for displaying what will be updated
3) "svn status --verbose (-v)" for displaying everything possible

My vote: I agree/believe that is the proper ordering of the typical usage
scenario.

(*) it is always possible we will/can revisit the issue if/when we have more
information and/or better ideas. but at this point in time, we can
definitely make a positive decision for what is "most useful"

>...
> * Secondary use: 'svn status --update" (-u)
>
> This subcommand adds information; specifically, it shows revision
> numbers on files that have impending updates. Network access is
> required.
>
> % svn status -u
> _ 21 *23 25 subdir/moo.c

Ah. Good. Forgot about listing the not-locally-modified files. Mo does have
a point about utility of all the numbers. Personally, I would suggest
dropping the "current head revision" and moving that to its own line.
Consider the following output:

$ ls -l foo
total 14
-rw-r--r-- 1 gstein users 11585 Sep 16 11:49 bar
-rw------- 1 gstein users 1052 Sep 16 11:49 baz

Note that it has a "different" line. Consider that "ps" outputs headers.

As long as that first line is easily identifiable by a parser, then we
should be okay:

$ svn status -u
# current revision: 25
_ 21 *23 subdir/moo.c
M 21 16 subdir/foo.c
A 20 15 subdir2/bar.c
_ 20 *24 subdir2/glorb.h
_ 20 *22 subdir2/blarg.h
D 21 12 include/bloo.h
_M 21 10 baz.h

$ set head='`svn status -u | sed /^#/s/.*: //`'
$ set files='`svn status -u | sed /^[^#]/s/[^ ]* *[^ ]* *[^ ]* *//`'

(that latter is probably handled better with the more powerful regexes, like
 Perl or Python: /{3}(\S+\s+)/ (or something like that))

It would also be nice if we could find a "good" way to identify the files
which need to be updated, without using a shell/regex metacharacter. The *
is very visible and its proximity to the server-changed-revision is good.
But maybe people have an alternate idea there.

[ and yah: if no alternates crop up, then we go with '*' for now ]

> * Maximum verbosity: 'svn status --verbose" (-v)
>
> Add this switch to see every single entry. The -v switch
> implies a -u switch.

Good call. Hadn't thought about that. Makes perfect sense.

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