On Thu, Sep 02, 2010 at 12:39:54PM -0400, Nate Coraor wrote:
I haven't actually done this since our local modifications are committed to the Galaxy codebase ;). However, it does make sense and as far as I know, UMN does this for their production Galaxy server. Perhaps Ry4an or others there can comment on whether this process still works correctly for them.
We do commit all of our local changes and have done renames on our config files. We maintain a code-flow like this:
galaxy-dist -> umn-galaxy-dev -> umn-galaxy-staging -> umn-galaxy-prod
where "->" could be read as "was cloned by".
So initially, we had just umn-galaxy-dev, where we did the renames of all of the config files, and then made local changes of our own. That, in turn was cloned by staging, and so on. In staging we have configuration options more suitable for a production server (debugging off, etc.) and those were commited in umn-galaxy-staging, but never pushed back to umn-galaxy-dev.
Mercurial does a pretty great job of merging, so when we do a 'hg pull' in umn-galaxy-dev to get the latest from galaxy-dist we mostly get clean merges on everything, and when we don't the history in umn-galaxy-dev let's me go back and see what the local-modification-developers were thinking. The only changesets that exist in staging that don't exist in dev are configuration settings (including different disk paths and database connection strings) and those always apply cleanly. Similarly the move from staging to prod just tweaks some settings, provides our welcome.html, and alters the database connection strings.
It might sound like over kill, but it's near-zero hassle, provides us with great local change tracking (who, what, when, and why) and provides us with an easy way to get local changes from dev to prod without the developers having access to prod.