开发Web服务器上的基本subversion服务器问题

Question

I've just set up a development web server, where people will be testing out some changes before making these changes on the production web server. Currently the web development team is used to using subversion to make their changes on the production server. I'd like to set up a SVN server on the development web server as well.

My question is this: How can I make it so subversion stores the repository in the Apache document root, so that files they check into the repository will go right into the docroot and be served by the web server.

As I have it set up now, it seems that when files are commited, they turn into virtual files in the svn repo directory (only visible with "svn ls file:///repo/file" rather than just "ls /var/www/file".

Thank you

Answer 1

That's not how subversion works. It doesn't normally store files in a format that's directly accessible. What you want to do is add a post-commit hook that will update a checked-out copy in the web directory. Google search for "subversion post-commit update" for more information.

Answer 2

You can control your source code using subversion, but the real issue is that you are changing your installation and then archiving it instead of the "normal" development routine; which is to make your changes and THEN install the changes.

The best method would be to keep the subversion server far away from the production web server. Your development box checks in changes to the subversion server. A single "special" build user checks out all the subversion stuff and makes a zip file (or something more appropriate) and that "zip file" is then copied to the production server and "installed".

This will give you more flexibility in deploying to your web server, and it will allow you to test changes on other non-critical web servers (if you ever decide to get so fancy) before you deploy to the production server. It will also prevent you from having mistakes that get checked in directly taking down the web server (as you can opt to not deploy a build to the web server while you check in subsequent "fixes" for the introduced mistakes).

Either way, you can use crontab or some other cron-like functionality to do a "nightly" package, etc. The key isn't to create more work that a person has to do, it's to create more work that automated programs can do simply so you have more security in the event of eventual upsets. Your role should be to decide if you want to install "this" package, and to run the command (or two) to install it.