Okay, thanks for all the feedback on status output format. I'm
responding to Greg's mail here, but have read the whole thread.
I'm completely persuaded on making "-M" the default (i.e., not
contacting the repository). Almost everyone is saying that their
usage pattern is to pass -M most of the time, and that far less often
they want out-of-date-ness information and the head revision, which
together require the dreaded network connection.
So yes, let's toss -M and make it the default, and get the extra
information only by passing a "--verbose", or whatever, flag. (There
would still be a separate flag saying to list all entries, right?)
However, I'm totally unconvinced by Greg Stein and others' cowardly
sophistries concerning output format consistency.
<ducks> :-)
I'll try to explain more clearly why I still feel *very* strongly that
we should stick with the same output format in all cases:
Greg Stein <gstein@lyra.org> writes:
> The perfect analogy is the following:
>
> $ ls
> $ ls -l
>
> The output is dramatically different, but I'm "habituated" to that
> difference because the two ls commands are *different* to me.
Yes, but `status' is not `ls'. Look at the two kinds of information
status gives back:
a) In the default case, it tells you what files you have modified.
b) With the --verbose flag, it *also* tells you what has been
modified in the repository. This information is most useful
when used *in conjunction* with the information about what files
you have modified locally -- therefore, it is important that
that the default local-mod information continue to be presented
the same way it usually is.
The point is, if you tell people about local mods in both cases, then
the interface should present *that* information the same way in both
cases, if possible. There's no point making the same thing look
different -- that just confuses people.
The key words are "if possible". The reason 'ls -l' doesn't maintain
format consistency is that it can't. There's way, way too much new
information being presented in the -l case.
But we can do it, because there's only a little bit of new information
being presented. All we have to do is not perturb the old data and
display the new data in specially reserved space. (And corollary to
that, users will rightly kick us if we *do* perturb the old data.)
I just don't see any justification for inventing a second output
format here. Ben, by the way, was never "proposing" the output
formats you saw in his mails -- he was just summing up the proposals
he'd seen so far, and explicitly does not endorse those formats. In
fact, if you go back and read the thread (or ask him), Ben *also*
wants a consistent, habituatible format, for the same reasons I do.
> > 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.
>
> IMO, the usage pattern of svn status disagrees with you. Out-of-dateness is
> rarely used. How often do you care whether something is out of date?
> Typically, you just go and update your WC. The more typical usage is to find
> what you've been working on and figure out what chunks are to be committed
> as a group.
>
> On the occasion where you need more information, then you have a switch to
> retrieve that information.
Agreed. I hereby strike point (2) from my mail. :-)
---------------------------------------------------------------------
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