My usual CVS tree setup is to setup a CVS tree for my project, then
import the OpenACS sources into that tree, and add whatever my
project demands.

This includes the occasional occurrence where I'll fix an OACS core
bug directly in my project tree.

But then the problem arises: Once the OACS core is fixed properly, I
don't want the version in my local tree to override the sources
imported from OACS core. I want to use the imported version.

How do I tell CVS to do that?

/Lars

Assuming your changes aren't exactly the same as the core patches, you need to back out your changes before bringing in the new core. To be able to do this cleanly, those changes need to have been committed seperately to anything else (such as changes in core to support your application, which you'll want to keep).

What you need to do is find out which commits of which files are the stuff you need to back out, get CVS to produce a suitable patch, then apply it.

For example, you've made a bunch of changes to foo.tcl, some of which are bugfixes (which you now want to back out) and some of which are in support of your application (which you want to keep).

cvs log foo.tcl shows you that foo.tcl is at revision 1.9, and the list of commit messages shows that 1.4 commit is the one you want to remove. cvs diff -r1.4 -r1.3 foo.tcl will give you a patch that takes the code from 1.4 to 1.3, which if nothing since has touched those lines will back out whatever change you've made. Apply that patch, repeat for other modified files, then you're set to import the updated core.

Another approach, which is perhaps better when you have changed lots of files, is to use vendor branches and merging. It is difficult but, once you get the hang of it, can make an otherwise unmanageable situation manageable.

I've written up how we manage the process on the Sloan project here: http://openacs.org/new-file-storage/one-file?file_id=396.

Now I want to those changes to go away, and the vendor branch to override anything on the trunk.

Suppose you have a checkout from the cvs HEAD in /web/dev and that there are no uncommitted changes in this checkout. Suppose further that you tagged your second import of the vendor code with the tag VendorImport2.

Say you want to revert readme.txt. Then you should do

cd /web/dev
cvs update -j HEAD -j VendorImport2 readme.txt

This command does two things: generates the patch and applies it to your working copy. You can check for correctness by doing a regular diff against the latest vendor version. When everything looks okay, commit the file

cvs commit -m "Reverting to latest vendor code." readme.txt

And from then on, updates to the vendor branch will prevail? Excellent!

Actually, no. CVS doesn't know where your commits came from, it just knows that you're off the vendor branch and committed some stuff. As far as I know, there is no way to get back to the virginal state short of hacking the repository files. If you find a way, let me know! OTOH, merging is really easy if all of your files match the vendor branch since there will be no conflicts.