On Mon, Sep 6, 2010 at 7:43 PM, Ry4an Brase <ry4an+galaxy@msi.umn.edu> wrote:
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.
Thanks for that detailed reply - I wasn't ignoring you, I've just been away a few days. I will see how I get on with this, but I foresee a number of pitfalls, first I need to learn the basics of hg. Having given ownership of the repository and its files to a non-login galaxy user, I am having trouble getting hg pull to work - it says "Not trusting file /opt/galaxy-dist/.hg/hgrc from untrusted user galaxy, group galaxy_admin)" even though I am a member of the group galaxy_admin. The initial work around I found online was to create a ~/.hgrc file containing the following: [trusted] users = * groups = * After that, I was able to run: sudo hg pull -u -r f09915c8da94 and it updated the code to the 8 September 2010 announcement, and seems to have merged my local (not yet checked in) changes fine. I doubt this is the best solution though. Given the advice from the other thread is to create the galaxy user account as a normal login account, do you normally run "hg pull" etc as the galaxy user? Thanks, Peter