[ic] Risks of websites served from Subversion or CVS checkouts

[ic at 3edge.com]

Mike Heins writes: 

> Quoting Jon Jensen (jon at endpoint.com):
>> On Tue, 19 Aug 2008, Peter wrote: 
>> 
>> >> If you use Subversion or CVS on any project, I recommend you look into how
>> >> your files are being served and see if there's anything being exposed.
>> >
>> > Just a side note, that this is bad practice anyways. 
>> 
>> A matter of opinion, and I disagree. 
>> 
>> > You should maintain your CVS, SVN, GIT, etc repositories separately from 
>> > your running copy of IC.  It is a good idea to use the standard, perl 
>> > Makefile.PL, make, make test, make install method to install your 
>> > running copy of IC (as well as other programs) as this method does not 
>> > copy the CVS, SVN, etc directories anyways, plus it checks certain 
>> > system dependencies and sets variables, etc. 
>> 
>> I think Perl's ExtUtils::MakeMaker (Makefile.PL) is a terrible way to roll 
>> out a complex Interchange site comprised of Interchange, admin, catalog 
>> ITL, custom Perl modules, HTML docroot, CSS, JavaScript, database DDL 
>> ("migration") files, etc. 
>> 
>> Version control systems have worked quite well at this for me. They also 
>> provide a sane way to deal with any intentional or unintentional changes 
>> made in production (such as mv_metadata.asc, page edits by administrative 
>> users, shipping.asc, etc.) and provide a way to do code rollouts.
> 
> We could easily set $relpat = qr/(\.\.|\.svn|CVS)/ in Vend::File
> to ignore CVS/Subversion directories.

Sounds like a quick and easy way to solve a possible issue, be it 'bad 
practise' or not :) 

CU, 

Gert