[ic] Risks of websites served from Subversion or CVS checkouts
Peter
peter at pajamian.dhs.org
Wed Aug 20 03:32:37 UTC 2008
On 08/19/2008 07:58 PM, Jon Jensen wrote:
> 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.
Actually I do a combination of both. I keep the version control
separate but I make any needed core changes there (those are rare and
usually end up in the IC core anyways). Other than that, IC is
sufficiently flexible for core add-ons (usertags, perl modules, etc) to
easily survive upgrades made in the traditional manner. Catalogs do not
get automatically upgraded.
I just think it's a very bad idea to allow version control to directly
update a running site.
Peter
More information about the interchange-users
mailing list