Use tags for your production environment. Always tag your releases, verify those tags in a testing environment (including that they have only the changes you actually want), then use the
svn switch (aka
svn sw) command on the production server to "update" to that tag.
In this way an accidental
svn up won't affect anything (provided you're following best practices and not developing in your tags...).
"Spot fixes" -- i.e. quick bug fixes that need to go into production now -- can be done by making the fix in trunk, copying the current production tag to a new tag, then merging the fix from trunk into the tag; then use the same
svn sw command to bring production up to that tag.
Also, @Shane's comment to use
svn export instead (exporting your tag) is a good one, as it guarantees that you won't be leaking revision history data through the .svn folders on your web server. Your promotion process would then consist of exporting the tag to a new (empty) folder, then doing a quick switcheroo by renaming the current production folder to something else, and then renaming the "staging" folder to the name for the production folder. For example, in Linux, it would look like this:
svn export http://www.example.com/path/to/your/tag staging/
mv production/ production-old/ && mv staging/ production/
Downside to this approach is that you can't use e.g.
svn info to find out what tag production is currently on, but if you have good policies and follow good practices you should have this information handy -- and it should be accurate -- anyway.