> -----Original Message-----
> From: Ben Collins-Sussman [mailto:sussman@collab.net]
> Sent: 13 September 2001 18:54
> 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.
+1 :)
>> 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.
Oo, I like that.
> > 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.
+1 on that one too.
>> 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'.
I'm with Ben on this one. The above change would make
svn status equivalent to svn status -M.
svn status _should_ show every file, since you want to know the
status of every file, not just the ones modified/added/etc.
>> 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.
I agree.
> 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 'cvs up' sloppily mixes two concepts. By deliberately
> separating the concepts in Subversion, and by producing simple status
> output, we hope to break this habit.
Which is really a good thing.
> 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.
Indeed.
Sander
PS. Ofcourse my votes are my personal opinion and non-binding.
---------------------------------------------------------------------
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