Forum OpenACS Q&A: CVS gurus: Revert to imported version

Collapse
Posted by Lars Pind on
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

Collapse
Posted by Ken Mayer on
It might be painful; what's essentially happened is that you and the vendor branch have changed the same chunk of code. When you import and then update, there's a strong probability of conflicts where your changes and the vendor-branch deltas collide. If the changes are *identical*, patch will notice that and skip it, otherwise, you'll have a lot of code conflicts to resolve before you can commit again.
Collapse
Posted by russ m on
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.

Collapse
Posted by Lars Pind on
Thanks a bunch, Russell. This was exaactly what I was looking for.

/Lars

Collapse
Posted by Andrew Grumet on
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: https://openacs.org/new-file-storage/one-file?file_id=396.

Collapse
Posted by Lars Pind on
I do have all my OpenACS sources on a vendor branch, and all that.

I've made local changes that I've committed on the trunk.

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

Question is: What's the command to tell cvs to do so?

/Lars

Collapse
Posted by Andrew Grumet on
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
Collapse
Posted by Lars Pind on
And from then on, updates to the vendor branch will prevail? Excellent!

Thanks,
/Lars

Collapse
Posted by Andrew Grumet on
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.