views:

1077

answers:

3

My Ubuntu server has Apache and Subversion installed. I use this server as a staging server, purely for testing purposes. I use Apache to host the web application, and Subversion to keep versioned copies of the source code.

My current workflow:

  • Make changes to a file
  • Commit the file to the Subversion repository
  • Upload the file new over SFTP to the Apache public directory
  • View the changes in my web browser

I would be much happier if my workflow was like this:

  • Make changes to a file
  • Commit the file to the Subversion repository
  • In the background, Subversion puts a copy of the committed file into the Apache public directory
  • View the changes in my web browser

I have very little server admin experience, and any help or pointers are appreciated. I heard that post-commit hooks are what I need, and that I can write bash scripts to do this, but I'm not sure where to start and didn't really find anything after quite a lot of Googling.

Thank you!

+7  A: 

The "official" answer is here.

I'm managing a website in my repository. How can I make the live site automatically update after every commit?

harpo
Great, thank you. That seems to be what I need!
rmh
A: 

It can be done, but automatically pushing every commit to the production website isn't always a good idea. Sometimes there are other changes that need to go along, and breaking the site because the new code is there, but the database schema hasn't been updated yet is just embarrassing.

What I tend to do instead is make the server checkout a copy of svn, then, once I'm ready with everything else that has to happen, I do an svn update on it.

But if you really wanted, you can put commands in the post-commit trigger, that will do everything automatically for you. This could include running a migration script on the server (if one exists for this change), to take care of any non-code changes that need to happen.

zigdon
My application checks the database schema when run, and gracefully displays a "not available right now" page if something is out of whack. Not to mention that this is a staging server, so it's the place I'd like things to go wrong ;). Thanks for the response, though.
rmh
A: 

I think the real, overarching question you should be asking yourself---which you may already have asked yourself of course---is this: "how can I test my code most easily before deploying it?"

I think a good answer is to install Apache on your development box and run it as your own user, with webroot and/or cgi path at /home/richardhenry/src/mywebsite (or whereever you check out your code).

That way, you can test your code without even committing. As a result, you won't litter your trunk with broken or useless commits. In general, keeping independent things independent tends to be A Good Idea (TM).

Alternatively, sync the web server against your working directory with rsync, or write a script which pushes your file(s) from the dev box to your staging server and add a Makefile rule which runs your script (or calls up rsync). If you want to be really fancy, use inotify or some other file notification monitor to run your script automatically.

Jonas Kölker