on 2007-08-20 15:59 Cliff Hirsch said the following:
Hey, nice catch Cliff.
To reiterate the point, if you use subversion to manage web
directories, you need to make sure that the .svn metadata will not be
served by apache.
Convenience sure makes me want to use this approach. And you could even
update the production "working copy" to a specific branch or tag, not just
the main trunk. But...it's still an update and conflicts would be a bear to
deal with in a production environment. Although there shouldn't be any
conflicts if the prod. Working copy isn't touched.
I manage several (>10) sites that are done in exactly this way -- the
webroot is a subversion working copy, and the webserver is instructed to
not serve up .svn directories. (You can also do this for applications,
but it is a bit trickier.)
It works wonderfully!
The key is to be as disciplined with the use of subversion in updating
the website as you would be if you did it using other shellscripts.
There are a few things you can do to help out:
1) Always do a dry run first. You'll catch any conflicts that arise
(there shouldn't be, if you don't edit files in the production area
independently). Also, you'll find out if one of your developers
accidentally committed a file that should be environment-independent
(for example, he added a config.php that would overwrite your production
area configuration with the test area, etc.)
If you've got people changing files in your production area in an
uncontrolled fashion, that's a bigger problem with which you must
deal--although you can mitigate it with subversion by committing BACK to
the repository from production :-)
2) If you have to make several concurrent changes (for example, you need
to make database changes or restart processes at the same time) you'll
need to do a bit of scripting to make things happen "atomically"--but
you'd have to do this ANYWAY, regardless of how you moved your files
into place.
The nice thing about subversion (or any good VCS) is that,
theoretically, if all you have to do is move files into place, you can
rollback to a last-known-good in the event of something horribly wrong
happening (and yes it's happened) in a relatively straightforward fashion.
Of course, YMMV.
//jbaltz
--
jerry b. altzman [EMAIL PROTECTED] www.jbaltz.com
thank you for contributing to the heat death of the universe.
_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com
Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php
