Using a working copy as your website is a pretty bad idea. That's what svn export is meant for.
It's especially bad because svn puts a .svn in each directory. With e.g. mercurial or git, you can tuck the (visible) site in a subdirectory of the repo itself (project/pages), and the .hg/.git (project/.hg|project/.git) won't be accessible.
Of course the best option is still to use exports and symlinks.
http://www.subversionary.org/martintomes/preventing-access-t... http://blog.samdevore.com/archives/2006/05/01/hivelogic-prev...
The ideal way is to not take the risk in the first place. You can't forget something you don't have to do.
Don't blame the tool, blame the individual for using it improperly.
I use Mercurial on all my websites (disabling access to .*/.hg of course) and never use FTP for anything.
It's clearly faster, it clearly is not safer, as the article demonstrate: if you forget to configure Apache to ignore the repo folders, your source code becomes available to the world.
> you can have hooks to do some cleanup and rollbacks are almost free
Export to versioned directories, then use symlinks to link your core to the right version of the site, and you get rollbacks for free as well. The only thing a WC gets you is deployment speed.
So when I deploy updates to sites we pull and update the changes then merge a locally stored patch queue to reconfigure the settings.
Because the settings are locally stored on the server (not in the site root) there is no way for people to steal the details from the public mercurial server :D