Forum OpenACS Q&A: Re: Upgrading a heavily modified site

Posted by Dave Bauer on

Have you changed the data model of any OpenACS package? If so you will need to reconcile your changes to any upgrades made to the data models in the newer version of OpenACS.

The procedure is basically this:

0) Make a backup of your database to test with.

1) Import latest OpenACS code onto a vendor branch.

2) Checkout a working copy of your web site into a staging directory.

3) cvs update your staging directory with the vendor branch you previously imported.

4) Resolve conflicts, this is the fun part. You really just have to look and make a decision here.

5) If there are data model upgrade scripts for acs-kernel. Run them through psql or sqlplus manually. This might not be an absolute requirement, but it doesn't hurt.

6) Start your staging service, go to the APM and upgrade any packages using the installer. When the installer offers to upgrade acs-kenerl, uncheck the box to load the sql file, as you have already installed that.

At any point, look out for error messages. If you have a sql file that doesn't load you will probably need to revert your database back to the previous step and resolve the problem before.

If you haven't made any changes to the packages data model and only made changes to tcl/adp templates and possibly added your own packages, this process should work fairly smoothly.

If anyone else has any comments or changes to this process please let me know.

Posted by Jeff Davis on
I have a couple of comments to add to what Dave mentioned. The first is that you should have the original reference code (4.6.2 in your case) and the new version both in there and to merge via something like
cvs update -j oacs-4-6-2 -j oacs-4-6-3 
It really should not be too bad, I merged the changes from 4.6.0-4.6.3 into HEAD (which I guess could be thought of as a heavily modified 4.6.0) and it was only 2 or 3 days work.

Another quicky solution is to diff the two distributions (diff -urN and exclude the CVS ids), apply the changes with patch and then check through the rejected patches. The advatage of this is you can more quickly discard changes to .adp files which are locally modified (which is sometimes a big source of conflicts in trying to merge).