Reputation: 2235
I'm planning to publish our live site today and I've read that the best option is to use svn export to avoid populating the working copy with .svn files, however this is no longer an issue with SVN 1.7 as the metadata is stored in a single file. Seems to me that using a working copy is much better than exporting as updating the live site would be as simple as running 'svn update'. Is there any reason not to checkout a working copy and use export?
Upvotes: 7
Views: 275
Reputation: 8257
The problem with using svn update is that it's too easy to update your live site. You might update to a version that doesn't work or is untested.
I'd recommend instead a hybrid approach - before releasing a new version, tag it, then svn switch the live site to that tag.
Obviously you still need to ensure you aren't serving up the root .svn directory.
Upvotes: 2
Reputation: 5949
Situation you're describing is a serious security threat.
As you might already know, Subversion stores its metafiles directly in working copy using .svn
folders. Each such folder has file entries with the list of all directories having the same level as the corresponding .svn
folder. In .svn
folders you can also find information about repository location, filesizes, modification dates and user logins. In the case you're deploying your site simply by checking out working copy to the htdocs
directory on the web-server, then using URL site.com/.svn/entries
you will see not only project filestructure, but also list of authors, latest changes, link to the repository, etc.
You can also find text-base
directory in each .svn
folder. It contains latest revision of all files placed under version control. Files in text-base
directory have .svn-base
extension, it allows to send its content directly to the browser output without interpreting it on the server side. Namely, it allows to see raw source code!
Nevertheless, there are simple solutions to this problem.
Apache:
<Directory ~ ".*\.svn">
Order allow,deny
Deny from all
Satisfy All
</Directory>
Nginx:
location ~ /.svn/ {
deny all;
}
To sum up, main disadvantage of such approach is that you should know about the threat and do not forget to prevent possibility of accessing .svn
directories from web.
Upvotes: 1