Your system of "separate libraries that load after the OpenACS core
and clobber the stock OpenACS libraries" seems, well, odd. I'm not
sure what the advantage is, since anytime you pull in a newer release
of OpenACS presumably you still have to look at the new stuff you'll
be clobbering, to make sure your custom code doing the clobbering is
still going to work with other parts of the system.
Given that, I don't really see the advantage over just committing
customizations to your own CVS repository. But leave that aside, you
have smart guys and apparently it works for you, so you must've had
reason to do it that way. And of course I've never tried your way
anyway.
As far as the non-clobbered parts of OpenACS go, do you always,
always leave those parts exactly stock, or do you sometimes
need to tweak things in those files to? If the latter, then yes, you
need to vendor import the stock OpenACS into your own repository, as
that's the only thing that's going let you easily sort out what stuff
is stock and what stuff is your customizations.
Personally, if I were you I'd vendor import any new version of OpenACS
into your own repository and merge it over to the trunk no matter
what. If you're not customizing OpenACS stuff, the import and merge
is easy and straightforward. If you do end up customizing stuff, it's
probably much simpler and easier to have started with the vendor
import than to try to do it retroactively. (But of course, I adopted
the cvs vendor branch religion long ago, so I've never actually
tried to do it retroactively... YMMV.)
In my mind, the great unanswered cvs question is, when I make fixes to
my own site, which in fact I should contribute to OpenACS, how to do
things? First do the work on stock OpenACS, then merge into my site,
or vice-versa? The only good answer is probably, "It depends." (And
contemplating that sort of thing makes me wish for the distributed
repository model and change-set based merges Bitkeeper and Arch are
reputed to have, rather than plain old dumpy CVS. But anyway...)
