On Wed, 2010-01-13 at 08:44 -0500, Soulliere, Robert wrote: > Hi Evergreen Community, > > > > In reviewing at the upgrading instructions, I would like to add > information on restoring customizations made to a local Evergreen > system after completing the upgrade and would like to find the best > procedures to accomplishing this? > > > > Is it possible to safely use diff/patch commands on the > entire /openils directory or to accomplish this in a few commands? > > > > For example could the user do the following: > > > > 1) Use diff to create patch for customizations on /openils > directory before upgrade and while running 1.4 > > 2) Upgrade to 1.6 > > 3) Patch files in /openils directory to restore the customizations > they made to files. > > > > Would this work or does the user need to use several targeted patches > such as one to update the default OPAC and a different one to update > Perl scripts? > > > > Could anyone share a set of precise universal diff/patch commands > they use or are there better methods to restore customizations after > an upgrade? > >
Hi Robert: At Conifer, I worked up a rough system for maintaining a patched Evergreen system using a combination of SVN and a poorly written shell script. Basically, the process and script works like this: 0. a. (Outside the script): Backup your existing /openils directory and Evergreen database. This way, if disaster happens, you can roll back with your tail between your legs having only suffered a bit of downtime. 0. b. (Outside the script): Install your new version of Evergreen to /openils/ and apply the SQL schema updates. 1. Checkout / update the SVN checkout of our customized files. The files are maintained in SVN in a parallel structure to Evergreen's install structure; so svn_root/branches/rel_1_6_0/var/circ/circ_duration.js would be our customized version of what would be installed by default to /openils/var/circ/circ_duration.js 2. Export the SVN files to an export directory to avoid polluting your install directory with the gross .svn subdirectories. 3. Walk through the parallel structure of the files from SVN and copy them over top of the corresponding files in /openils 4. For skins, we take a slightly different and more complex tack. For each skin, we try to maintain only the minimum set of customized files. Roughly speaking, for each skin "foo", we copy the entire contents of the default skin into our new /openils/var/web/opac/skin/foo directory, then copy the customized skin/foo files from SVN over top of the corresponding /openils files, then munge all of the internal links that point to /default/ to /foo/ (no sense in keeping all of these files in SVN for an easily automated change), then munge some of the JavaScript variables to meet our preferences for that skin. Oh, for the XUL thing we have very few customizations, but we maintain /openils/var/web/xul/current/ as a symlink that points to our true current staff client and overlay a file or too there. That's pretty much it. Obviously you want to diff each of the files in your SVN repo against the new versions of the files in the upcoming release to ensure that you're not missing out on major new functionality, etc. Our customizations start at http://svn.open-ils.org/trac/ILS-Contrib/browser/conifer/branches/rel_1_6_0 and the old semi-automated update script I wrote is at http://svn.open-ils.org/trac/ILS-Contrib/browser/conifer/branches/rel_1_6_0/tools/patch_conifer.sh - it's badly in need of updating and polishing, though, so be warned. _______________________________________________ OPEN-ILS-DOCUMENTATION mailing list [email protected] http://list.georgialibraries.org/mailman/listinfo/open-ils-documentation
