On 7/10/06, Jim C. [email protected] wrote:
files not being covered by svn (like logs, and the database itself).
I’d recommend using rdiff for keeping offsite versions of your
production site; perhaps having database dumps taken and included in the
rdiff tree (using mysqldump, if you’re on mysql). But you must check
that you can restore your entire site from the backups, otherwise
My vote is for Subversion as well, it’s pretty painless to deal with
if you’re careful of what Jim was pointing out. Also, don’t be tempted
to let subversion handle all the webwork for you, it can get slow when
you have a load of files.
At our firm the new policy is to develop on our own work computers,
commit when we’re happy, and when all the testing is done we checkout
a copy into the staging folder where we can see how it’ll do on the
real server. Finally if that all checks out we checkout a copy to the
live area of the server and go home for the evening.
As Jim points out any dynamic areas won’t be well covered by
subversion so if you need the logs for your production site you’ll
have to set up a svn hook to commit those files or use a cron script
however often. Either way will probably break at some point so be
careful and do it manually occasionally.
Lastly, svn doesn’t keep track of permissions so remember to check
that tmp, log, and public have write access and that your dispatch has
execute (which subversion will track if you get into the subversion
properties but I don’t know how so I just say to check it.) They have
a pretty distinct smell when the perms are wrong so if you see
Application Error but no log output then you have your criminal in
We also replicate the entire mysql database to each test box via the
built-in replication. It’s really heavy-weight but it works nicely for
those that don’t have the mysql server in the office.
Hope that helps,