On 13 Sep 2001 14:10:22 -0500
Ben Collins-Sussman <sussman@collab.net> wrote:
> Mo DeJong <supermo@bayarea.net> writes:
>
> > 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?
>
> 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.
Both of these use cases are perfectly reasonable. While I certainly think
that case 1 is going to be much more common than case 2, I don't think
we need to sacrifice 2 to get 1. I just think that the current svn status
output is not the best way to satisfy case 2. Let me explain what I mean
with an example.
For the sake of this example, pretend I have a small repo with only
6 files (the problem would get worse with more files in the repo).
% svn status
_ 95 ( 95) ./ac-helpers/install.sh
_ 95 ( 95) ./ac-helpers/svn-apache.m4
_ 95 ( 95) ./ac-helpers/svn-macros.m4
M 95 ( 95) ./autogen.sh
M 95 ( 95) ./build.conf
A 0 ( 95) ./buildcheck.sh
This status output certainly helps me see local mods, so we are covered there.
Now I want to examine up-to-dateness, what do I do? I would start with:
"_ 95 ( 95) ./ac-helpers/install.sh"
My local version number of 95 matches the server rev of 95 so
I would conclude that this file is up to date with respect to the
server. I would then rinse and repeat this process for each and
every line in the status output. Now lets say someone checked
in a change to install.sh, the revision on the server would be
upped and I would see that new server rev number in the
output of each and every line. The end user would not have
any way to know that it was install.sh that had been updated.
What I am suggesting is that we do this "compare rev numbers"
check for the user and only present them with interesting status info
like when a revision transition for a file actually does something.
For example, we could use 'N' to indicate that the local file needs
a patch from the server.
% svn status
N 95 ( 96) ./ac-helpers/install.sh
_ 95 ( 96) ./ac-helpers/svn-apache.m4
_ 95 ( 96) ./ac-helpers/svn-macros.m4
M 95 ( 96) ./autogen.sh
M 95 ( 96) ./build.conf
A 0 ( 96) ./buildcheck.sh
That does a much better job of telling the user what is going to be
pulled down during the next call to `svn update`. If that is the case,
there really is no reason to show files that are not modified or in
need of an update at all. By the same token, we don't even need
to display the actual revision number. We could drastically
simplify the output and get rid of the need for the -M flag
by only displaying those files that were changed locally
or on the server.
% svn status
N ./ac-helpers/install.sh
M ./autogen.sh
M ./build.conf
A ./buildcheck.sh
Of course, some folks might really want to see the rev numbers.
Perhaps showing the rev numbers in this case would be a better
use for the --verbose flag to the status subcommand. After all,
do we really get any benefit from printing a status line for
a file that is not changed locally or on the server?
...
> > > 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?
>
> You're right, I retract. {commit, update, checkout, diff} are all
> recursive by default. Let's leave status recursive too.
Whew.
> > 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.
>
> I already committed something similar, revision 100. 'svn st -M'
> now works the way you suggested.
Great, thanks much.
Mo
---------------------------------------------------------------------
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