"Manage site with Subversion" is too common and unclean definition. How do you manage?
- Working Copies are on local Dev-boxes, repository on some special host and sites are unversioned files, result of export repo
- Sites are additional "update-only" Working Copies of repository
In any case:
- Two-tier (DEV and PROD spaces) development is widely-used method
- DEV may reflect state of trunk (no needs for additional branch and merge-to-branch actions), depending from your workflow
- Shared DEV space for a team of development with unmanaged automatic updates have serious drawback - it case of dumb post-update hook changes in testing of developer one after commit can be overwritten by next commit from another developer two
Answer on question "which software use to update the sites?" depends from answer on question "How sites managed" and "Which access-methods can be used in order to update sites". Because they (software and method) can be
and more or less complex post-commit hook
In case of unversioned tree as on the same host as repo you can use in post-commit hook
- Full export of repo-tree:
svn export file:///<PATH-TO-REPO> <TEMP-DIR> & mv -r <TEMP-DIR> <SITE-ROOT>
- Export of only changed files in revision:
svnlook changed give you list of changed files with relative paths, which you have to collect and copy to correct destination. Sample
>svnlook.exe -r 24 changed .
You have to process statuses (first column) A|U (added/updated), maybe D also (deleted)
Targets of each commit (pre-check before processing files) can be verified with
svnlook dirs-changed. For the same revision as in example above
>svnlook.exe -r 24 dirs-changed .