[ic] site.txt in standard

[Gert van der Spoel]

> -----Original Message-----
> From: interchange-users-bounces at icdevgroup.org [mailto:interchange-
> users-bounces at icdevgroup.org] On Behalf Of Angus Rogerson
> Sent: Tuesday, January 26, 2010 4:58 AM
> To: interchange-users at icdevgroup.org
> Subject: Re: [ic] site.txt in standard
> 
> 
> On 24-Jan-10, at 10:00 AM, Gert van der Spoel wrote:
> 
> > Hi,
> >
> > Quite a few developers (including myself) are using site.txt next to
> > variable.txt to be able to split out some Variables that could be /
> are
> > different in for example a development environment compared to the
> > production environment.
> >
> > This split could also be useful when the site is kept up to date
> using
> > a
> > version control system, where you can decide to for example ignore
> > site.txt
> > so it does not get deployed to production ...
> >
> > I'd like to suggest splitting variable.txt and put some variables in
> > site.txt .. catalog.cfg already has a line with regard to this, so it
> > will
> > require only an addition in the dbconf/... directories similar to the
> > variable.dbm ...
> >
> > The site variables are not shown in the admin under Administration,
> > but can
> > be found still via the tables tab ... However this would be a 'todo'
> > for the
> > admin UI ...
> >
> > Below the standard variable.txt , I've marked with a * the variables
> > which I
> > think should be in site.txt ... Anybody has any other ideas?
> >
> > CU,
> >
> > Gert
> >
> > <snip>
> 
> 
> We have been using a site.txt for a while to manage version control
> across multiple stores and development/staging/production environments.
> 
> To make our version control work, we tell cvs to ignore site.txt, and
> instead manage multiple files of the form site_<catalogname>.txt. When
> we create a new catalog, cvs dumps all the site_whatever files, and we
> create a symbolic link from site.txt to site_catalogname.txt. So in
> each catalog, there are a bunch of files, updated by cvs, which
> interchange does not know about:
> 
> site_ar.txt
> site_book.txt
> site_tech.txt
> etc
> 
> and one link: site.txt -> site_ar.txt so that interchange only notices
> the right one.
> 
> In the book catalog, of course, site.txt is linked to site_book.txt
> 
> We also have 3 environments: development (where developers might be
> working on files in the interchange/ tree for various different
> projects with unpredictable results), staging (where we do final
> testing, and the interchange/ tree is stable) and production (which
> ideally is stable and well tested in staging). We use a similar
> strategy to the site.txt by having multiple versions of interchange.cfg
> (interchange.cfg.devel, .stage and .prodn). In each environment, cvs
> downloads copies of all the interchange.cfg.whatever files, and we link
> interchange.cfg to the appropriate one.
> 
> For some of the variables which Gert has indicated below, we build the
> variable from a machine name defined in interchange.cfg.whatever and a
> catalog name from site_whatever.txt. For example, in catalog.cfg we
> define:
> Variable   IMAGE_DIR
> https://@@SERVER_NAME@@/rs/interchange/__CATALOG_NAME__
> 
> By having the right variables in the right files we can migrate a
> catalog from development to staging (which are on the same machine so
> have some similar variables (for the machine name) and some different
> variables (for the staging vs development users)) and to production
> (which is on a different machine and has different settings such as
> merchant codes and production encryption keys).
> 
> So, ... I like Gert's suggestion. Careful consideration is certainly
> needed to get the right variables defined in the right files.
> 
> Angus
> 
> Angus Rogerson
> Retail Services, University of Waterloo

Hi Angus,

Another approach I've seen and am thinking might work out 'better' (for
example would not need a change to the Admin UI) is the introduction of a
catalog_local.cfg which is included in catalog.cfg

Instead of having site.txt you'd have the Variable settings in
catalog_local.cfg ...
In your case that would make a catalog_tech.cfg , catalog_ar.cfg symlinked
at the right locations.

I think that either approach would work, but considering a couple of things
the catalog_local.cfg approach might have slightly more pros:
- catalog.cfg is really about configuring your catalog,  variable.txt is
more focused on display ( I think ) ... 
- the actual start of using site.txt in the demo would require an update to
the Admin UI

So I suppose I change my proposal slightly to become:
- remove site.txt from standard
- introduce catalog_local.cfg to move the things to that I had marked with a
* in my previous mail
- include catalog_local.cfg in catalog.cfg

This change I do not think would hurt existing catalogs and will not cause
any backward compatibility isues as it would be part of the creating of a
new catalog.

CU,

Gert