[nycphp-talk] Webserver file access (and version control)
Jerry B. Altzman
jbaltz at altzman.com
Mon Aug 20 16:54:44 EDT 2007
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
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.
jerry b. altzman jbaltz at altzman.com www.jbaltz.com
thank you for contributing to the heat death of the universe.
More information about the talk