Ben Collins-Sussman <sussman@collab.net> writes:
> On Tue, 2004-06-01 at 07:57, C. Michael Pilato wrote:
>
> > > ? foo.o # svn doesn't manage foo.o
> > > ! some_dir # svn manages this, but it's either missing or incomplete
> > > ~ qux # versioned as dir, but is file, or vice versa
> > > +I .screenrc # this file is ignored
> > > A + moved_dir # added with history of where it came from
> > > M + moved_dir/README # added with history and has local modifications
> > > D stuff/fish.c # this file is scheduled for deletion
> >
> >
> > This breaks the example. 'svn status' will not show 'I' output unless
> > --no-ignores is passed to it. If you plan to show 'I' output in the
> > example, you should have the example use --no-ignores.
>
> Hmmm. Then my official opinion is that we just toss the "$ svn status"
> line. Stop pretending this is *literal* output... just say it's a list
> of the different things the status command *can* print, depending on how
> it's invoked.
+1. *Every time* I see that block in the book, it looks very much
like a tabular description of status code, and very much *not* like
real-world status output. I'd almost go so far as to say we should
just toss the example wholesale since we have a table describing the
codes, but there is benefit in seeing how status looks when it is run.
So I'm going to suggest instead that we break that "example" up into
several examples that actually resemble real-world scenarios.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 3 16:03:18 2004