Re: update vs status, where should local mods be displayed?

On Thu, Sep 13, 2001 at 02:10:22PM -0500, Ben Collins-Sussman wrote:
>...
> There are two common use-cases for 'svn status', I believe.
>
> 1. To see local mods
>
> The user wants to know exactly what to commit, or what would be
> committed. No other clutter.
>
> 2. To examine 'up-to-dateness'.
>
> The user wants to know which files are out-of-date. This means seeing
> local revision numbers on files, but *mostly* seeing out-of-date
> flags. The user can then predict exactly what will be patched when
> 'svn up' is run.

Agreed.

Today, "svn status" can do (1) (but it isn't the default), and it cannot do
(2). It can give you a hint that *something* is going to be updated because
the server rev is newer than your files. But it can't do (2).

> The heart of the this debate is: "which use case is more common?"
> Whichever is more common -- that should be the default.

Case (1) is more common, I'd say. How often do people want to see what is
new, but *not* pull it down? IMO, the typically pattern is:

(edit, edit, edit)
$ svn status
(figure out commit msg)
$ svn commit
$ svn up
(repeat)

> On this issue, my own experience may be skewed;

I believe it is :-)

To actually do case (2), we need to send an update report to the server and
then specially process the results -- we skip the whole "fetch" part of the
report processing. Effectively, it would "cvs -n up" but we'd make it a part
of the "svn status" subcommand.

Hmm. I believe we have a table of four commands:

          Show actual update activity?
                YES NO
All files 1 2
Affected files 3 4

The -M switch is flipping us between options (2) and (4). We have nothing
for options 1,3 (until we do the special report processing, per above). But
if we *do* the modified-report, then how do we differentiate the four cases?

I like Mo's idea of tossing -M and simply using different levels of
verbosity. And -M stops making sense once we change the default to be -M. If
we assume --verbose gives us all the files, then what flag hits the server
for the extended information? Is it a flag, or a separate subcommand?

How about these command lines for the 4 cases:

1) svn status --will-update --verbose
2) svn status --verbose
3) svn status --will-update
4) svn status

(need better names for will-update)

I'm tempted to say that if you want to see status on your local changes,
then to use "svn status". If you want to know about what will happen with an
update, then use "svn update". But that puts us back into the CVS mode.

Well... that is enuf for my analysis. Basically, I think "svn status" should
default to the -M switch. --verbose gives you info on all files. No real
answer for "check the server for true update info."

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