On 7/27/2011 8:57 AM, Markus Schaber wrote:
Hi, Andy,
Von: Andy Canfield [mailto:andy.canfi...@pimco.mobi]
- Using 'svn checkout', the working web site will have the
subversion control files in the .svn subdirectory, which might be a
security hole.
You could use some pattern based access control (Apache is very
configurable in that respect) to prevent remote access to all pathes
containing .svn in their url.
And the security hole should be not that large, as the .svn directory
usually does not contain any authentication information.
Subversion 1.7 will further improve on that situation, you only have
a single .svn directory then. And you can use the trick of directing
the webserver to a subdir of your working copy, so the .svn directory
is completely out of the web servers path.
Alternately, if it is a Linux based host, you can use a tool like FSVS
which also doesn't create the .svn metadata directories in the file
system. (Although we use FSVS more in a tripwire / change log fashion
on our servers to track and note configuration changes.) But SVN 1.7
with a central .svn folder will also make things much easier.
One thing that I do wish SVN would add to their export command would be
a "sync" where it would only bring down files that are actually changed
content instead of bringing everything down. Which would make the SVN
export method more bandwidth friendly.
