Forum OpenACS Q&A: Re: CVS strategy for maintaining OpenACS and local codebase
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...)