Reuven, yes, Ola is right in that CVS is the only mechanism OpenACS
has to do what you want. And while it does require some extra work on
your part (unlike say, the way rpms can be told to "leave modified
files unchanged"), it actually gives you a complete solution, and for
anybody who was able to customize the ADP and TCL pages in the first
place, the extra CVS work should be no big deal.
I agree with Ola that in some fashion, you always want to import a
copy of the OpenACS code onto a vendor branch in your local "my
private OpenACS fork" CVS repository, and merge your customizations
and resolve conflicts there. (You probably also want to be careful to
always import a tagged version of OpenACS, e.g. oacs-4-5-rc-1, not
just the untagged tip of the development trunk.) And you'll also want
at least one separate checkout directly from the OpenACS CVS
repository, so you can conveniently do cvs log
and the
like against the OpenACS repository, and otherwise check what's going
on in the development sources.
FYI, it's been way too long since I last updated them with new stuff
I've learned or found usefull, but my
Version Control
docs on www.piskorski.com go into many of the CVS issures mentioned
above.