Upgrading the OpenACS files

Chosing a Method to Upgrade your Files

OpenACS is distributed in many different ways: +Upgrading the OpenACS files

Prev	Chapter 5. Upgrading	Next

Upgrading the OpenACS files

Chosing a Method to Upgrade your Files

OpenACS is distributed in many different ways:

as a collection of files
as one big tarball
via CVS
via automatic download from within the APM (package manager)

Upgrades work by first changing the file system (via any @@ -11,7 +11,7 @@ describes whether or not you need to be upgrading using this page or not: the section called “Upgrading an OpenACS 5.0.0 or greater installation” -

Methods of upgrading OpenACS files

Upgrading files for a site which is not in a CVS repository. Unpack the tarball into a new directory and copy its +

Methods of upgrading OpenACS files

Upgrading files for a site which is not in a CVS repository. Unpack the tarball into a new directory and copy its contents on top of your working directory. Or just 'install software', select remote repository, and upgrade your files from there.

[root root]# su - $OPENACS_SERVICE_NAME
@@ -32,21 +32,21 @@
         with the latest OpenACS version, without overriding your own
         local customizations. 
This diagram explains the basic idea. However, the
         labels are incorrect. Step 1(a) has been removed, and Step
-        1(b) should be labelled Step 1.
Figure 5.2. Upgrading a local CVS repository

Step 0: Set up a working CVS checkout. To get your OpenACS code into your local CVS
+        1(b) should be labelled Step 1.
Figure 5.2. Upgrading a local CVS repository

Step 0: Set up a working CVS checkout. To get your OpenACS code into your local CVS
                 repository, you will set up a working CVS checkout of
-                OpenACS. When you want to update your site, you'll
+                OpenACS. When you want to update your site, you'll
                 update the working CVS checkout, import those changes
                 into your local CVS checkout, create a temporary CVS
                 checkout to merge your local changes, fix any
                 conflicts, commit your changes, and then update your
-                site. It sounds complicated, but it's not too bad, and
-                it is the best way to work around CVS's limitations.
This part describes how to set up your working CVS
-        checkout. Once it is set up, you'll be able to update any
+                site. It sounds complicated, but it's not too bad, and
+                it is the best way to work around CVS's limitations.
This part describes how to set up your working CVS
+        checkout. Once it is set up, you'll be able to update any
         packages using the existing working CVS checkout. We use one
         dedicated directory for each branch of OpenACS - if you are
         using OpenACS 5.1,x, you will need a 5.1 checkout. That will
         be good for 5.1, 5.11, 5.12, and so on. But when you want to
-        upgrade to OpenACS 5.2, you'll need to check out another
+        upgrade to OpenACS 5.2, you'll need to check out another
         branch.
The openacs-5-1-compat tag identifies the latest released version of OpenACS 5.1 (ie, 5.1.3 or 5.1.4) and the latest compatible version of each package.  Each minor release of OpenACS since 5.0 has this tagging structure.  For example, OpenACS 5.1.x has openacs-5-1-compat.
You will want to separately check out all the
                 packages you are using.
               
[root root]# su - $OPENACS_SERVICE_NAME
@@ -55,7 +55,7 @@
 [$OPENACS_SERVICE_NAME aolserver]$ cd openacs-4/packages
 [$OPENACS_SERVICE_NAME aolserver]$ cvs -d :pserver:anonymous@cvs.openacs.org:/cvsroot checkout -r openacs-5-1-compat packagename packagename2...
 [$OPENACS_SERVICE_NAME aolserver]$ cd ../..
-[$OPENACS_SERVICE_NAME aolserver]$ mv openacs-4 openacs-5-1
Make sure your working CVS checkout doesn't have
+[$OPENACS_SERVICE_NAME aolserver]$ mv openacs-4 openacs-5-1

Make sure your working CVS checkout doesn't have the entire CVS tree from OpenACS. A good way to check this is if it has a contrib directory. If it does, you probably checked out the entire tree. You might want to @@ -74,7 +74,7 @@ [$OPENACS_SERVICE_NAME myfirstpackage]$ cvs -d /var/lib/cvs/ import -m "importing package" $OPENACS_SERVICE_NAME/packages/myfirstpackage OpenACS openacs-5-1

Create a new directory as temporary working space to reconcile conflicts between the new files and your current work. The example uses the cvs keyword yesterday, making - the assumption that you haven't checked in new code to + the assumption that you haven't checked in new code to your local tree in the last day. This section should be improved to use tags instead of the keyword yesterday!

[$OPENACS_SERVICE_NAME openacs-5.1]$  cd /var/lib/aolserver
 [$OPENACS_SERVICE_NAME tmp]$ rm -rf $OPENACS_SERVICE_NAME-upgrade
@@ -83,10 +83,10 @@
 (CVS feedback here)

The file /var/tmp/openacs-upgrade/cvs.txt contains the results of the upgrade. If you changed files that are part of the OpenACS tarball and those changes conflict, - you'll have to manually reconcile them. Use the emacs + you'll have to manually reconcile them. Use the emacs command M-x sort-lines (you may have to click Ctrl-space at the beginning of the - file, and go to the end, and then try M-x sort-lines) and then, for each line that starts with a C, open that file and manually resolve the conflict by deleting the excess lines. When you're finished, or if there aren't any conflicts, save and exit.

Once you've fixed any conflicts, commit the new code + file, and go to the end, and then try M-x sort-lines) and then, for each line that starts with a C, open that file and manually resolve the conflict by deleting the excess lines. When you're finished, or if there aren't any conflicts, save and exit.

Once you've fixed any conflicts, commit the new code to your local tree.

[$OPENACS_SERVICE_NAME tmp]$ cd $OPENACS_SERVICE_NAME-upgrade
 [$OPENACS_SERVICE_NAME $OPENACS_SERVICE_NAME-upgrade]$ cvs commit -m "Upgraded to 5.1"

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.

[$OPENACS_SERVICE_NAME $OPENACS_SERVICE_NAME-upgrade]$ cd /var/lib/aolserver/$OPENACS_SERVICE_NAME
 [$OPENACS_SERVICE_NAME $OPENACS_SERVICE_NAME]$ cvs up -Pd
@@ -97,7 +97,7 @@
       
[$OPENACS_SERVICE_NAME ~]$ cd /var/lib/aolserver/$OPENACS_SERVICE_NAME
 [$OPENACS_SERVICE_NAME $OPENACS_SERVICE_NAME]$ cvs up -Pd
 (CVS feedback)
-[$OPENACS_SERVICE_NAME $OPENACS_SERVICE_NAME]$

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:

Declare a freeze on new cvs updates - ie, you cannot run cvs update +[$OPENACS_SERVICE_NAME $OPENACS_SERVICE_NAME]$

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:

Declare a freeze on new cvs updates - ie, you cannot run cvs update on the production site
Make a manual backup of the production site in addition to the automated backups
Import the new code (for example, OpenACS 5.0.4, openacs-5-0-compat versions of