On Fri, Jul 29, 2011 at 7:54 AM, Thomas Harold <thomas-lists_at_nybeta.com> wrote:
> On 7/27/2011 8:57 AM, Markus Schaber wrote:
>>
>> Hi, Andy,
>>
>> Von: Andy Canfield [mailto:andy.canfield_at_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.
I've supported this by maintaining a separate "rsync" accessible
target to which a subverion post-commit keeps things updated after
every change, and which uses "exclude" options to avoid propagating
the .svn subdirectories. One has to be cautios about mutiple
post-commits occurring at the same time in a busy environment, but in
a small environment with infrequent updates it's handy.
It was also very, very handy when my colleagues needed a duplicatable
working copy *with* the .svn subdirectories, to speed deployment to
NTFS based systems which do not have recently updated Subversion
clients with the recently announced massive NTFS speedsups.
Replication was much, much faster than checkouts before that recent
update.
Received on 2011-07-29 21:52:09 CEST