I would like to know if there is any way to make it so that when I commit changes using Subversion, that the changes are automatically reflected on my server in the testing folder? Perhaps this idea is irrational. I'm struggling to get a good big-picture view here. If I kept the subversion repository on the server, would that be reasonable?
views:
128answers:
5I would like to know if there is any way to make it so that when I commit changes using Subversion, that the changes are automatically reflected on my server in the testing folder?
Yes, certainly. What you want is called a post-commit hook -- see this link for the relevant SVN FAQ.
The general strategy is to have a working copy on your server. When you commit, the script gets called, and its job is to cause your server's working copy to initiate an svn update
.
A post-commit hook should help you: I'm managing a website in my repository. How can I make the live site automatically update after every commit?
An alternative (and for me, preferable) is to use a post-build push after a successful build on a CI server. There is no sense in putting code on a server that does not do the right thing.
You could set something up as simple as a cron job to check for changes every minute or so.
However in my experience, I've found it more flexible to set up a continuous integration / build server like TeamCity or Hudson with a job that checks the svn repository every minute or so for updates. If there are updates you can "deploy" them to the testing directory. The advantage of going this route is that you could automate additional tasks such as restarting the web server and/or running unit tests and only updating on success, etc.
Also, it is not entirely necessary for the subversion server to be on the same server as your environment that needs updating.