This question is really a question about release procedures (and tools), rather than system administration, but here's my best answer:
Any recent version of Subversion takes excellent care of your configuration management needs, but, like Peter said, it's not a deployment tool. One option would be to build deployment into your regular build infrastructure (e.g 'make deploy') and manage your deployment rules alongside your code.
From a configuration management point of view, you need to keep track of everything your application needs to function, including code, external libraries (in specific versions), webserver, OS versions, etc. 'make deploy' should try to ensure all those things exist before it attempts to deploy a new version.
Tools like Hudson can also handle deployment for you, but you'll still need to tell it what to do and I simply prefer to keep my configuration management procedures as simple as possible. One example would be to let Hudson invoke 'make deploy' but store no other information in Hudson that you'd need to recover to recreate on additional machines.
How often are you going to be doing releases that need to be deployed? I would consider something along the lines of tagging your webapp into tags/ and having a post-commit mechanism that knows that tags/webapp-1.0.4 needs to be exported to your webroot. If your webapp is large, consider having the hook drop a special file in /tmp which a cronjob checks every minute and takes appropriate action on.
If you want more detailed answer, please elaborate on your release schedule, size of codebase, choice of language, OS environment and dependencies.