subversion books ?

[Bill Hernandez]

On Mar 31, 2009, at 6:32 AM, Ryan Schmidt wrote:

> On Mar 30, 2009, at 19:26, Bill Hernandez wrote:
>
>> After trying to get subversion to work remotely via apache webdav  
>> and having dismal luck and many questions over the weekend, I went  
>> down to the local nerdbooks.com and bought three books this  
>> afternoon. They all had different aspects that I liked as I browsed  
>> through them, so instead of buying one as planned, I came home with  
>> three. But that's OK I'll read one and use the other two for  
>> reference.
>>
>> They (nerdbooks.com) do mostly all web based sales, but luckily  
>> they have a warehouse in Richardson, TX  (Dallas area).
>>
>> I don't know how their prices compare, but they do technical books  
>> only, and they have the most incredible selection.
>>
>> I posted the book info here in case this is helpful to others
>>
>> The Pragmatic Programmers
>> Pragmatic Version Control using Subversion
>> ISBN : 0-9776166-5-7
>> Price : $34.95
>> Discount Price : $20.97
>>
>> Bruce Perens Open Source Series
>> Subversion Version Control
>> ISBN : 978-0-13-185518-2
>> Price : $44.99
>> Discount Price : $26.54
>>
>> O'Reilly
>> Version Control with Subversion
>> ISBN : 978-0-596-51033-6
>> Price : $39.99
>> Discount Price : $25.99
>
> I've seen the Pragmatic book recommended many times on the  
> Subversion Users list. And the O'Reilly book is of course the one  
> that is written by the authors of Subversion and is available free  
> online at http://svnbook.org/
>
> You may also want to pass your recommendations on to the Subversion  
> Users list.


Ryan,

I was a little concerned about mentioning nerdbooks.com for fear that  
it would get me in trouble. I understand that promoting any business  
on a forum is not good thing, because it can get out of hand and after  
a while people will try to push all kinds of businesses, but I've been  
buying from nerdbooks for a couple of years, they have always been  
great to work with, their service and pricing has always been great.

I thought that by listing the prices, any members of the forum who saw  
the info might benefit from their great prices.

Last night I read the first 43 pages of 'Pragmatic Version Control  
using Subversion, and the book is awesome. So far it has explained  
part of the BIG picture very well. I can't wait to finish it...

The first 43 pages have already explained some of my basic questions,  
some of which I have listed below. With any luck this book, and the  
other two should help to answer a lot of my questions below...

For those of us who are not computer science majors all this stuff is  
mostly foreign (buzzwords). When I tried getting involved with svn I  
found mostly tutorials and information on how to setup a basic local  
svn repository and use the commands, but nothing that really explained  
the big picture, such as :

( 1 ) what components are required (clients, daemons, or servers, gui  
interface, directories, data, etc) :
        ( a ) on the local machines ?
        ( b ) on the server ?
        ( c ) where do they, or where should they each get installed  
(preferred locations) ?
        ( d ) what permissions do they need to in order to protect the  
data from intrusion, and
        ( e ) still be accessible to the users, and
        ( f ) also accessible to the daemons/servers/clients ?
        ( g ) which method is best suited to remote repositories :
               ( 1 ) WebDav, or
               ( 2 ) something else ('svnserve' which I read about  
yesterday as an alternative to WebDav) ?
        ( h ) how relatively secure can an average person make this  
stuff without knowing about unix jails, etc ?
        ( i ) how risky is doing this without being a unix security  
master guru ?

( 2 ) what's the difference between the :
        ( a ) trunk,
        ( b ) branches,
        ( c ) tags, etc. and
        ( d ) when do you use, or transition from one to another ?
        ( e ) what do they really mean ?
        ( f ) some of the articles mentioned a trunk, others never did ?
        ( g ) some articles mentioned import, add, create, and other  
commands, but the overall strategy of how to design a successful  
environment was not something I found ?
        ( i ) after trying to create a remote repository using a gui  
client, and later
              using bash $ 'svnadmin create https://my-domain/path/2/my-repository'
              over the weekend, I finally found one article mentioning  
that svnadmin
              cannot be used to create a remote repository, from which  
I surmised,
              that you have to issue that command on the remote  
server, either
              physically or perhaps via ssh.

( 3 ) what about checkout, merging, sandbox, workspace. I assume  
(workspace == sandbox), etc.

         ( a ) must checkout location be the workspace (one workspace) ?
                ( 1 ) i.e. one physical folder where you check  
everything in/out of,
                ( 2 ) so that the svn software (daemon/server/client/ 
etc) can keep track
                       of the changes without undue overhead, or
        ( b )  in relation to the workspace, can you :
                ( 1 ) keep your existing directory hierarchy within  
the htdocs directory, or
                ( 2 ) use the drive hierarchy itself, and just use  
them to make changes, or
                ( 3 ) will the svn software have a harder time  
tracking changes, possibly
                       get confused, or not work at all ?

         Assuming that you want your entire htdocs directory to be  
under version control, I think having a duplicate in the sandbox would  
create more things to keep track of.  I don't see this as what they  
(the svn creators) intended...

         I guess the biggie is how do you transition from just having  
a massive amount of files/directories on a drive to a working svn  
model of all that data, and then do it remotely so that multiple  
machines/users can benefit. In the case of htdocs, those dirs have to  
reside in a specific place within the grasp of apache, so you don't  
have to get involved creating/changing symlinks in the workspace, or  
aliases in httpd.conf.

         ...and not everything in the repository can be aliased or  
symlinked back to htdocs anyway (stuff that's not meant for the web),  
so you can't have one central alias, you would have to create/maintain  
many. I am sure this is not the way it was intended.

         some documents I found implied that you should make a  
repository for each project, which seems to me, would quickly get out  
of hand. I would think that it would be better to have one huge  
repository for all your projects, sub-projects, etc., which would  
physically translate into some, not all, directories on your home  
directory, root directory, web directory. etc. I would envision the  
htdocs directory to be under subversion, but split into specific  
directories (projects), such as libraries, documents, etc.

I think I have to think about the previous paragraph some more...

         From a strategic point of view, there are a boatload of  
questions, for which I have no answers, issues that need to be  
considered in order to get this going, or at least get it going  
successfully. I can see two months down the road starting over again  
because the initial setup was not established correctly and is either  
seriously flawed, too cumbersome, has weaknesses, or creates more  
overhead and user workload.

I know I keep going back to htdocs, but...

( 4 ) when you have something like the htdocs folder containing  
thousands of files, :
         ( a ) do you :
                 ( 1 ) create duplicates in the workspace and
                 ( 2 ) import them into the repository, or
         ( b ) do you :
                 ( 1 ) import them into the repository, then
                 ( 2 ) check them out to the workspace, or
         ( c ) better yet, :
                 ( 1 ) import them, and
                 ( 2 ) leave them where they were, such as /somepath/ 
htdocs/projects/whatever_dir/
                         and work on them in place (their original  
location) ?

( 5 ) how do you transition the thousands of folders, files, etc from  
a myriad of projects on your computer to svn ?

( 6 ) what method is most advantageous/secure for a remote repository  
model that can be accessed by a couple of workstations (from home),  
powerbook (from starbucks), etc ?

         In my particular case, I would be the only user, but a local  
repository would not work very well because I would like to use  
several machines/locations to access and keep the work synchronized. I  
read somewhere that you can sync multiple local repositories, but I  
don't want to do that, I want to have one central repository.

These are some of the questions I was trying to figure out answers  
for...

I even tried watching some video tutorials I found on the web, but  
great as the effort was on the part of those trying to help, all this  
cannot be covered in a few minutes, and not all of them had the same  
goals. The ones I viewed dealt with local repositories.

One last thing, as I was researching all this, it became clearly  
evident that as much software as I have written over the years, I have  
never had a good tracking system other than a simple database, for  
features, bugs, etc. So I decided that since I am taking this leap, it  
would be good to get 'trac' working with 'svn', and do it all in one  
shot rather than have to come back to 'trac' later on.

I looked at a lot of webpages dealing with getting 'trac' up and  
going, and came away thinking that svn will be child's play compared  
to getting 'trac' going. Hopefully I will be wrong.

I found a package that installs trac/subversion but I was hoping to  
get this all working using MacPorts.

http://www.jumpbox.com/

Thanks for all the suggestions, and help...

Bill Hernandez
Plano, Texas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20090331/c1f58ab5/attachment.html>