Forum OpenACS Q&A: upgrade, update, CVS

Collapse
Posted by Matthew Terenzio on
Hey folks,

I have OACS 4 installed and working, but I obviously am going to want
to keep current, given this stage of development. I'm not experienced
using the CVS. What , in general, is involved in this process. Should I
use it for  development sites only or production also? I just need a
little conceptual nudge in this area.

Collapse
Posted by Jun Yamog on
Hi Matthew,

I believe you can use OACS 4 for production site if you know what you are doing.  I have built a couple of production site with it and so has my officemates.  OACS 4 comes from ACS 4.2 Tcl which has seen some production already.

Currently from what know the CVS copy is broken because Don B is doing a major revamp regarding sort trees.  I have used OACS 4 by synch with the CVS for several months.  Basically I do a cvs update on my local copy of openacs once in a while.  I look for what files are updated and if the files are core files I check out the cvs history or status of the file.  Do a cvs import to my development tree, manually merge the conflicts if needed.

Alot also does heavily the way you code.  To keep my code away from OACS code, I use as much as the public procs.  I never change any proc or datamodel.  I just write wrapper procs and do the modification I need after the real proc has been called.  Rather the altering any table or trigger, just add a table and relate it or just add another trigger.
As long as you are aware that the code that your are working on as code as others are working on you will be ok.Keep up to date by following the bboards, you may want to know if there are major changes that will affect your code.

For starters see Pascal's nice document at:

https://openacs.org/new-file-storage/download/cvs.html?version_id=140

A useful tip: You can see the difference between the repository and your copy without altering your copy using "cvs -n update". (The "-n" switch means "do nothing".) Also, even if cvs update overwrites your locally modified files, it saves a copy of your file with ".#" prepended to the filename. Pascal, can you update your document with this information?

There is an explanation of what the update output flags mean (e.g. P, M, C, etc) somewhere. I usually check the info file in emacs.

Collapse
Posted by Gilbert Wong on
I believe Don finished the sort key edits and committed them earlier this week.  If you are working with a copy of the OpenACS 4 code from the CVS repository and there are changes to the core data models, you will most likely have to rebuild the database.  It's a minor inconvenience, but it looks like the data model is pretty stable now, so this might not be an issue for the next release...
Collapse
Posted by Arjun Sanyal on
To clarify and correct my last post, "cvs update" (no flags) merges your local changes with the current state of the repository and informs you of conflicts. "cvs update -C" saves your local modifications in the .# files while fetching fresh copies from the repository. This flag is useful for those times when you totally screw up your working copy ... i.e. "the planning phase".
Collapse
Posted by Fred Yankowski on
What is the procedure to "rebuild the database"?  I know how to use CVS to get the latest committed code and how to merge my tcl/html/adp changes with that code, but I don't know to deal with changes to the data-model.  Is there some dump/restore procedure for this?  How do others with sites running OpenACS 4 handle data migration to track changes in the data model?
Collapse
Posted by Don Baccus on
Thus far we haven't made any effort to provide upgrade scripts for the changes we've made during development.  The datamodel is explicitly unstable until we hit "beta".  We're nearing that point but aren't quite there yet.

People who've built OpenACS 4 sites while its been under development have understood that until it stabilizes, they're at risk of being somewhat orphaned or having to figure out their own datamodel migration path.  Particularly using Postgres - which is one reason why the few serious sites out there based on our pre-release code are Oracle, not Postgres, based (the Oracle data model's been relatively stable).

In the future we do plan to provide upgrade scripts.  The package model is a big help here, if someone vastly rewrites (say) the bboard package and datamodel (as I'm tempted to do everytime I look at the code) one option is to simply fork off a new package.  Then people can continue to fix bugs and incrementally improve the old version, which would be a huge help for those maintaining existing sites.

But incremental improvements will, before too much longer, come with upgrade scripts.

For now, though, you need to drop your database and reinstall from scratch if you're using PG and want to synch with the latest CVS sources.  For this reason I'd recommend you only use it for development sites until we officially declare a "beta" or perhaps even the final release.

Most of the datamodel changes in the PG version were made to enhance performance after initial scalability testing showed that some of our earlier decisions didn't work well in practice, in Postgres.

On the other hand, as has been pointed out the Oracle version's in pretty good shape for rolling out a production site.