If you can set up the production server to access the SVN repo via a secure channel, such as https with webdav maybe try the following:
Create a script on the Production server that allows you to enter a tag directory and/or revision number/date and perform an svn export. This way, the prod server is pulling the changes from svn.
Now, if you have a way to have this script called securely from, say a commit script. Voila, you have automation.
Most importantly, you do not want an automatic update performed to the prod server that you were not planning for.
To solve this:
The commit script should only call the prod update script when something is committed to "/path/to/tags/release/dir"
Make sure only appropriate change control staff (or whoever currently controls the manual prod deplyment) have the ability to perform an svn copy to this directory in the repo.
For example, say your repo is set up as:
/yourWebsite
--> /branches
--> /trunk
--> /tags
----> /releases
The commit that would trigger the auto deployment to prod would be something like:
svn copy https://mySvnRepo/yourWebSite/trunk
https://mySvnRepo/yourWebSite/tags/releases/x.y
-m "Tagging for production deployment"
Rolling back can be achieved by making a commit to a previous releases directory. Note however, that this will not cause new files that were added to be rolled back.
Of course, your mileage may vary; this is only a suggestion for your investigation.
You should take time to consider the security implications and potential for disaster if set up incorrectly.
Hope this helps, even if only to get you thinking of other solutions.
