Re: svn commit: r9916 - trunk/doc/book/book
"C. Michael Pilato" <[email protected]> 02 Jun 2004 21:58:26 -0500
| Newsgroups | gmane.mail.eyebrowse.devel,gmane.comp.version-control.subversion.svn |
|---|---|
| Message-ID | <m3aczltkj1.fsf__15113.5327447721$1086271411@localhost.localdomain> |
Ben Collins-Sussman <[email protected]> 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.