5 ms·

Using a working copy as your website is a pretty bad idea. That's what svn export is meant for.

by Sujan 17y ago

dolinsky 17y ago
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.
masklinn 17y ago
. 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.
- chrismear 17y ago
  Of course, it's not too tricky to configure, say, Apache to block access to all the .svn directories: http://www.subversionary.org/martintomes/preventing-access-to-svn-folders-in-apache http://www.subversionary.org/martintomes/preventing-access-t... http://blog.samdevore.com/archives/2006/05/01/hivelogic-preventing-svn-exposure/ http://blog.samdevore.com/archives/2006/05/01/hivelogic-prev...
  - masklinn 17y ago
    It's not, but if you ever forget to set this config anywhere, you're hosed. The ideal way is to not take the risk in the first place. You can't forget something you don't have to do.
  - masklinn 17y ago
    Case in point to complement my previous post: http://fr.php.net/.svn/entries http://fr.php.net/.svn/entries secure http://fr2.php.net/.svn/entries http://fr2.php.net/.svn/entries open
- thismat 17y ago
  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.
hlidotbe 17y ago
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.
- ErrantX 17y ago
  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
- deleted 17y ago
  [deleted]
- masklinn 17y ago
  > 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.

Using a working copy as your website is a pretty bad idea. That's what svn export is meant for.

by Sujan 17y ago

Using a working copy as your website is a pretty bad idea. That's what svn export is meant for.

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.

masklinn 17y ago

. 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.

chrismear 17y ago
Of course, it's not too tricky to configure, say, Apache to block access to all the .svn directories: http://www.subversionary.org/martintomes/preventing-access-to-svn-folders-in-apache http://www.subversionary.org/martintomes/preventing-access-t... http://blog.samdevore.com/archives/2006/05/01/hivelogic-preventing-svn-exposure/ http://blog.samdevore.com/archives/2006/05/01/hivelogic-prev...
- masklinn 17y ago
  It's not, but if you ever forget to set this config anywhere, you're hosed. The ideal way is to not take the risk in the first place. You can't forget something you don't have to do.
- masklinn 17y ago
  Case in point to complement my previous post: http://fr.php.net/.svn/entries http://fr.php.net/.svn/entries secure http://fr2.php.net/.svn/entries http://fr2.php.net/.svn/entries open
thismat 17y ago
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.

hlidotbe 17y ago

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.

ErrantX 17y ago
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
deleted 17y ago
[deleted]
masklinn 17y ago
> 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.