[nycphp-talk] Webserver file access (and version control)

Jerry B. Altzman jbaltz at
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.'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.

jerry b. altzman        jbaltz at
thank you for contributing to the heat death of the universe.

More information about the talk mailing list