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.
Spot on. Even with proper auth rules it would still trouble me knowing I had my source exposed to the world. I'm a big fan of exports and now, thanks to you and masskin(sp?), really digging the symlinks idea.
I will echo the sentiments of Sujan and masklinn. A production machine should not have a checked out version of a repository on it ever. If you want the ability to rollback, you have the last N exports of your repo in their versioned folders with a symlink from a 'current' folder pointing to the revision you want on live.
Don't blame the tool, blame the individual for using it improperly.
Using a working copy allows you to deploy your website faster and safer (only the changes gets transfered, you can have hooks to do some cleanup and rollbacks are almost free).
I use Mercurial on all my websites (disabling access to .*/.hg of course) and never use FTP for anything.
> Using a working copy allows you to deploy your website faster and safer
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.
one good idea I had was using a patch queue to insert database and other "secret" settings into a Mercurial pull.
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
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.