Index: openacs-4/packages/acs-core-docs/www/upgrade-openacs-files.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/upgrade-openacs-files.html,v diff -u -r1.8 -r1.8.2.1 --- openacs-4/packages/acs-core-docs/www/upgrade-openacs-files.html 4 Mar 2004 14:09:22 -0000 1.8 +++ openacs-4/packages/acs-core-docs/www/upgrade-openacs-files.html 18 Apr 2004 11:55:50 -0000 1.8.2.1 @@ -1,44 +1,55 @@ Upgrading the OpenACS files

Upgrading the OpenACS files

OpenACS is distributed as a collection of files, available as one big tarball, via CVS, and via automatic download from within the APM. Upgrades work by first changing the file system (via any of the previous methods), and then using the APM to scan the file system, find upgrade scripts, and execute them. This section describes how to upgrade the file system. Starting with OpenACS 5.0, this section can generally be skipped because the OpenACS APM can directly download new files from the openacs.org repository.

Many OpenACS site developers operate their own CVS repository to keep track of changes from the release OpenACS code. This part describes how to import the latest OpenACS version into your own repository. If you are using CVS, you will unpack the OpenACS 4.6 tarball into a working directory and then import that directory into cvs. If you have changed files in the core packages, cvs will attempt to merge your changes. You may have to manually merge some conflicts. When that's finished, you can update your normal development checkout directory and the new files will appear. If you aren't using CVS, you can unpack the tarball on top of your existing tree, but any customizations you've made to the kernel or core packages will be erased.

View comments on this page at openacs.org
+[service0 openacs-upgrade]$ cvs commit -m "Upgraded to 4.6"
  • Step 3: Upgrade your local staging site.�Update your working tree with the new files. The CVS flags ensure that new directories are created and pruned directories destroyed.

    [service0 openacs-upgrade]$ cd /var/lib/aolserver/service0
    +[service0 service0]$ cvs up -Pd
    +(CVS feedback)
    +[service0 service0]$ exit
    +[root root]# 
  • + Upgrading files for a site using the OpenACS.org CVS repository +

    1. [service0 ~]$ cd /var/lib/aolserver/service0
      +[service0 service0]$ cvs up -Pd
      +(CVS feedback)
      +[service0 service0]$

    Upgrading a Production Site Safely

    If you are upgrading a production OpenACS site which is on a private CVS tree, this process lets you do the upgrade without risking extended downtime or an unusable site:

    1. Declare a freeze on new cvs updates - ie, you cannot run cvs update + on the production site

    2. + Make a manual backup of the production site in addition to the + automated backups

    3. Import the new code (for example, OpenACS 5.0.4, openacs-5-0-compat versions of + ETP, blogger, and other applications) into a "vendor branch" of the + service0 CVS tree, as described in "Upgrading a local CVS repository", step 1, above. + As soon as we do this, any cvs update command on production might bring new code onto the production site, which + would be bad.

      Do step 2 above (merging conflicts in a service0-upgrade working tree).

    4. + Manually resolve any conflicts in the working upgrade tree +

    5. Use the upgrade script and a recent backup of the production database, to ake + a new upgraded database called service0-upgrade. Now we + have a new website called service0-upgrade. +

    6. + Test the service0-upgrade site +

    7. If service0-upgrade is fully functional, do the real upgrade.

      1. Take down the service0 site and put up a "down for maintenance" page.

      2. Repeat the upgrade with the most recent database

      3. Test the that the new site is functional. If so, change the upgraded site to respond to + yourserver.net requests. If not, bring the original production site back up and return to the merge.

    View comments on this page at openacs.org