Mo DeJong <supermo@bayarea.net> writes:
> (Possible output)
>
> % svn update
> % svn -M status
> M 95 ( 95) ./configure.in
> M 95 ( 95) ./gen-make.py
> A 0 ( 95) ./buildcheck.sh
I agree, right now "-M" is only printing (M)odified and (C)onflicted
files. But I believe that scheduling an object for (A)ddition,
(D)eletion or (R)eplacement should show up with this flag as well.
They're all local modifications in their own way. I can make this
change if others agree.
> For example, here is a quick snip from the output of status
> on my machine:
>
> _ 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
>
>
> What information does the first three lines really provide?
> Can't we communicate that the install.sh, svn-apache.m4,
> and svn-macros.m4 files are up to date and have not been
> changed by not printing a line of output for them?
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.
However -- you do raise an issue that has been on the back-burner for
a while. Right now, our 'status' command does *not* match all the
functionality of CVS's 'status' command (other than being easier to
read). Specifically, our status command is unable to tell the user if
a particular file actually out-of-date content-wise. Just because you
have version 90 of foo.c, and the repository is at 95, doesn't mean
that foo.c has changed contents!
Issue #385 talks about this. Our plan is to possibly print the
repository revision on its own first line, and use the column in
parenthesis to show whether the file is *actually* different on the
server. This could be done by placing an asterisk in the parens, or
it could be much fancier -- like displaying the revision number in
which this file last changed.
> This can be quite a problem even for a small repo
> with hundreds of entries. Sifting through thousands
> of entries worth of output would be even worse.
Different issue. 'svn status -n' shows only the CWD
(--nonrecursive). I've long thought that -n should be the implied
*default*, because people rarely want to see hundreds of lines of
output all at once. (For the same reason people run 'ls', and rarely
run 'ls -R'.) I'd love to make that change.
> What I am suggesting is that the default output of the
> status command should not display every file. Instead
> the default should display info for locally modified
> file, locally added files, and locally deleted files
> (I assume modified props would also apply here). We
> could add a `svn status -v` option to print out the
> really verbose output that is currently displayed.
I don't like this. Like I said, my own personal habits are to use
'svn st' much like I use 'ls'. "Show me the state of everything in my
CWD." I want to know not only about local mods, but mixed-revisions
as well. If I want to know what to commit (or what will happen when I
commit), then I run 'svn st -M'.
> On a related but separate note, should the `svn update`
> command do something similar? It currently ignores
> local mods, adds, and deletes.
I'm not sure why you want this behavior, other than "it's what I'm
used to with CVS". They're logically different ideas. When updating
my working copy, why should local mods be printed? Updates should
tell me what's being patched, *not* give me an overview of my working
copy status. That's what 'svn status' is for.
Many CVS users have developed a habit of running 'svn up' *soley* for
the purpose of seeing their local mods displayed conveniently. This
habit exists because 1) CVS's status command produces hideous output,
and 2) because 'svn up' sloppily mixes two concepts. By deliberately
separating the concepts in Subversion, and by producing simple status
output, we hope to break this habit.
Todo: we really need folks to document these new or not-new behaviors
-- either by adding to doc/user/manual/, or perhaps somebody could
volunteer to write a short, consise "Subversion for Former CVS Users"
document which explains all the differences. That document would be
invaluable.
---------------------------------------------------------------------
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