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
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
