Up: Feedback on Version Control with Subversion
ward181079 at yahoo.com
Thu Oct 5 14:43:51 CDT 2006
Can you please let me know if you have received the message below?
Ward Bergmans <ward181079 at yahoo.com> wrote: Hello,
First of all I want to say that I find Version Control with Subversion a real good book. It explains version control and Subversion very clearly.
I've got some feedback on Version Control with Subversion for Subversion 1.2 (book compiled from Revision 2147) Here it comes:
page 54 Tracking Merges Manually:
Add a footnote to the text "demonstrated in the earlier example". A footnote like "In paragraph 'Copying Specific Changes' on page 52."
page 55 Best Practices for Merging:
Extra best practice:
Commit workspace before merging.
- Because then the commit after the merge is "ported r#:r# from x" instead of "ported r#:r# from x and changed this and also that and that and..."
- Because if a merge goes wrong you can simply runt svn revert without losing local modifications.
page 57 Merging a Whole Branch to Another:
Fix mistake "and has burned many a new user!" to "and has burned may new users!".
page 90 Migrating a Repository:
Change the steps to:
3. Create new empty ones in their place using your new svnadmin.
7. Validate that the migration is successful, and move your old repositories out of the way.
I think the term "working copy authorization" is better than "software authorization". Because it is possible that you manage the same working copy with multiple software applications.
For example, you can use Subclipe to manage my working copy, but when you have not started Eclipse and just want to edit a little thing very fast, then you can use the svn command line client.
The way I understand your book is that the lock is kept in the working copy, and not in the software. So "working copy authorization" is a better name.
Chapter 5, section "Repository Creation and Configuration":
Add a subsection "FSFS" which explains how to create a FSFS repository (under a Unix like operating system) with the proper rights. Now only the Berkeley DB repository is explained in more detail.
When I create a FSFS repository under Linux as explained in your book (svnadmin crate fs-type fsfs /path/to/repos). And then do an initial import as explained in your book. I get the following error:
$ svn import . file:///home/svnrepo --message 'initial repository layout'
svn: Can't create directory '/home/svnrepo/db/transactions/0-1.txn': Permission denied
It would be very helpful if your snvbook would explain more about FSFS repository configuration.
I know that a solution to my problem above could be to give everybody read and write access on all the repository files. But I don't want to do that.
Therefore I would like to know:
- Which files need to be read to read from the repository?
- Which files need to be read to write to the repository?
- Which files need to be written to write to the repository?
- How can I easily give the proper rights to these files? For every possible situation, like "owner and group can read and write, others can't access the repository", "owner and group can read and write, others can only read", etc.
(...I don't want to change the rights file by file, because that takes ages. Therefore I want to know an easy way)
Can you please send me the information that I miss in chapter 5 as soon as you got it? So that I can already read it before you officially release it in the book.
(from The Netherlands)
Get your email and more, right on the new Yahoo.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the svnbook-dev