Forum OpenACS Q&A: CVS strategy for maintaining OpenACS and local codebase

We're (Greenpeace) trying to figure out the best way to rebuild and maintain our CVS repository, which contains code from the OpenACS community repository we update infrequently, and our own modules we develop ongoingly. As far as I can tell, the whole concept of "vendor tags" is designed so that you can modify the shared code, and then merge your own changes with the new versions of the shared code. We have a number of customizations to the OpenACS core in place, but  our custom code does not live in the OpenACS packages - we use separate libraries that load after the OpenACS core and clobber the stock OpenACS libraries. So our code lives in different package directories, and we don't really need to merge changes  in the filesystem. (We do have to logically merge the changes, which will involve updating our custom libraries as needed). Any suggestions as the best way to handle the updating the shared OpenACS code? Do we still need to use vendor tags and perform a fresh import each time you want to update to a new version of OpenACs?


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...)