[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Feedback on Subversion Book

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2003-12-01 18:37:30 CET

Jennifer Bevan wrote:
> Hi,
> I just read Chapters 1-8 of the Subversion book. It was
> very helpful, but I did notice some errors, clarity problems,
> and consistency issues. So, I'm posting my feedback so that
> those working on the Book can peruse it in their infinite
> free time.

Excellent. Thank you for the feedback.

In many cases you know what should be changed. Would you care to help out even more by editing the book source files and sending a patch? That would involve something like:

svn co http://svn.collab.net/repos/svn/trunk svn
cd svn/doc/book
Read the text files in that directory (at least README and HACKING).
Edit book/*.xml
make all-html
svn diff > book.patch
Write a log message at the top of book.patch
E-mail book.patch to us

That would be really good, but it's still useful to have your comments anyway.

Some comments on the less obvious points:

> Where: Chapter 5, Repository Recovery
> Current Value:
> ---------------
> Make sure that you run this command as the user that owns and manages
> the database, not just as root. Part of the recovery process might
> involve recreating from scratch various database files (shared memory
> regions, for example). Recovering as root will create those files such
> that they are owned by root, which means that even after you restore
> connectivity to your repository, regular users will be unable to access it.
> --------------
> Comment:
> Shouldn't svnadmin create also be run in this manner?
> Otherwise, you have to chown/chgrp just like you would if you
> ran svnadmin recover as root. Of course, with svnadmin create
> there could be a problem writing the top-level directory if
> apache/nobody doesn't have write permission there, so that should
> perhaps be mentioned too.

Yes. Isn't there already some discussion of that, maybe in a FAQ? It would be good to link the discussions together, at least.

> Where: Chapter 6, Manipulating Properties, first example
> Current Value:
> ----------
> property `copyright' set on 'calc/button.c'
> ----------
> Comment:
> why a backquote?

There used to be an almost random mixture of back-quotes and normal single and double quotes in the program's output. Now we have standardised on the normal single quote, and this bit of the book is out of date.

> Where: Chapter 6, Manipulating Properties, propedit
> Current Value:
> ----------
> When you run the command, svn invokes your editor program on a temporary
> file that contains the current value of the property
> ---------
> Comment:
> You may want to add that if you try this on a binary file then

("on a binary property")

> the result may be ugly (maybe in a footnote, those are usually
> amusing).

Good idea. In theory you should be able to specify an appropriate editor, e.g. "svn propedit --editor-cmd=gimp icon myfile". (In practice this fails for me with "failure during string recoding". I shall report that as a bug.)

> Where: Chapter 8, svn Switches
> Current Value:
> ------------
> --new ARG
> Uses ARG as the newer target.
> --old ARG
> Uses ARG as the older target.
> ------------
> Comment:
> Unclear (after having read chapters 1-7). This probably
> would make sense after seeing an example with a "newer"
> and "older" target, but up to this point such terminology
> hasn't been used. Hmmm. Neither --new nor --old are
> listed as a legal switch for *any* of the svn subcommands.

Hmm, yes. Chapter 8 has quite a lot of problems. We really need a way of checking it automatically against the actual program operation (output of "svn help SUBCOMMAND").

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 1 18:34:22 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.