On 13 Sep 2001 12:33:47 -0500
Ben Collins-Sussman <sussman@collab.net> wrote:
> Sander, I'm glad you agree with everything I said. :-)
>
> But, let me summarize the proposed changes on the table:
>
> 1. 'svn status' is capable of showing local mods (M, A, D, R) only,
> and it's also capable of showing local mods plus everything else
> (for seeing mixed revisions in a directory.)
>
> To be decided: what behavior should be the "default", and which
> should require a switch?
>
> It sounds like Mo wants the first behavior to be the default. I
> personally like the second behavior to be the default, which is
> what we have now.
The current `svn status` behavior could be activated when the --verbose
switch is passed. By default, the suggested (M,A,D,R) with -M
behavior should be used (and we could remove -M, simple is good).
The functionality the -M provides is so useful that it should
be the default. This would provide a much more "cvs update"
like behavior and would avoid overloading users with a line
of output for each and every file in the repository. Sure, we
could just punt and tell users they can add "status -M" to
a ~/.svnrc file. Thing is, bad defaults is one of the things that
bothers me most about CVS.
Let me ask this. What is the benefit of spewing out a status
line for each and every file in the repo by default? What
question does the end user seek to answer by looking at
all this status output? Is there an end user question that
can't be answered by the output if -M style output was
the default?
> 2. 'svn status' can show only the current directory, or it can
> display a long recursive list.
>
> To be decided: what behavior should be the "default", and which
> should require a switch?
>
> I personally would like to make nonrecursive the default, which is
> not the status quo. I haven't heard anyone defending the status
> quo yet. (?)
I could not disagree more strongly. Why make this one command
non-recursive by default when update is not? Users are supposed
to use status instead of update, right?
> I think an important use-case of 'svn status' is to get an overall
> snapshot of your directory -- seeing exactly how "mixed" your working
> copy revisions are.
Why? I can't imaging end users will really care that much about how
mixed files revision numbers are. That does not really tell me anything
other than the fact that someone has checked something into the repo
since I last did an update. Users would care much more about whether
or not they needed to do an update to pull down changes for a specific
file before a commit or about local changes they have made. I think we
need to be careful to avoid setting defaults that are good for developers
but don't really help end users.
cheers
Mo
P.S.
Here is a quick snip from my local copy of svn_cl__print_status_list.
It implements the (M,A,D,R) thing Ben suggested above.
if ((status->text_status == svn_wc_status_added)
|| (status->prop_status == svn_wc_status_added)
|| (status->text_status == svn_wc_status_conflicted)
|| (status->prop_status == svn_wc_status_conflicted)
|| (status->text_status == svn_wc_status_deleted)
|| (status->prop_status == svn_wc_status_deleted)
|| (status->text_status == svn_wc_status_modified)
|| (status->prop_status == svn_wc_status_modified)
|| (status->text_status == svn_wc_status_merged)
|| (status->prop_status == svn_wc_status_merged)
|| (status->text_status == svn_wc_status_replaced)
|| (status->prop_status == svn_wc_status_replaced))
svn_cl__print_status (svn_stringbuf_create (path, pool), status);
---------------------------------------------------------------------
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:41 2006