On Oct 1, 2011, at 18:15, Grant wrote: > Would I need to install subversion on the production machine, or would > the subversion server running on the dev machine just treat the > production machine as a target destination and use SSH to transfer the > files?
> So I'll be OK if I commit changes to the dev repository and then > update from dev to production instead of using rsync. > > I'm trying to get the dev/staging/production thing clear in my mind. > The way I imagine this working is I install a copy of my production > machine onto a dev machine and a developer works on some of the code > on that dev machine and is able to test his changes on that machine as > he goes. Once everything is done and verified, his changes are > exported to the production machine. Where does the staging machine > come in? Why is it needed in addition to the dev machine? > > I can see how multiple developers would really complicate things. Now > that I think about it, wouldn't development on the dev machine be > impossible if two developers are working on separate things that > happen to interact with each other? They wouldn't be able to test > their changes properly as they're coding. How is that handled? A > separate dev machine for each developer? > > I think I'm missing something here. Could someone straighten me out? Again I strongly encourage you to spend time reading the book. The first several chapters should solidify for you how people work with Subversion. There's no sense in us explaining it all here on the list when writers have already spent years refining the words in the book. But I'll try to summarize a few things briefly anyway: There is a repository -- a database -- that holds your code. The current version and all past versions, including, if you like, branches. This could be on any server you like -- the production server, the development server, a completely separate server -- doesn't really matter. That server will run some kind of Subversion server software -- svnserve perhaps, or Apache 2 with mod_dav_svn. Anyone who works on the code will check out a working copy from the repository onto their work machine. They will modify the code, then they will test the changes on their local work machine (which in your case means they will be running a web server and whatever else necessary to run the web site on their work machine). Once satisfied the changes are correct, they'll commit the changes back to the repository, with a message describing what they did. At any time you can choose to pull a version of the files from the repository and put them on a staging web server for testing, or on a production web server. How you do so is up to you. Generally you would "tag" your code before you put it anywhere, so that you give that state of the code a meaningful name that can be referred to later as needed. If any of the above sounds unfamiliar then you really need to spend more time with the book. The book doesn't specifically address developing web sites with Subversion, but it's not too difficult. If the web servers can reach the repository server, you can go to the web server and check out or update a working copy from the repository server directly. If not, you can use any other computer to get a working copy from the repository, and scp or ftp or rsync that to the web server. Or you could automate deployment using tools like SVN::Notify::Mirror, which watches your repository for the creation of tags following a certain naming convention (that you define) and deploys those versions. (I recommend this approach.)
