strange merge issue between two local branches

[Tim Mooney]

[apologies for the length -- I tried to provide anything that might be
relevant to determining the source the problem we're running into]

All-

We've had some local patches against the UW IMAP distribution that add
some additional functionality we need.  Now that we're getting better at
using CVS (thanks mainly to people on this list!), we want to use CVS to
track the vendor sources and our local mods against any particular
version.

We've run into an odd problem that I don't understand, while trying to
merge our local mods on a branch rooted off the vendor 2002.RC6 version
forward to a local branch rooted off the vendor 2002c1 version.  I'm
hoping someone can explain what we might have done incorrectly, or what
the problem might be.

We're using (Red Hat) CVS 1.11.1p1 on both the client and the box with the
repository.

This first bit likely isn't relevant since the first vendor import and
the two local branches rooted off that import don't really play any part
in the subsequent issue, but I thought I better include it for
completeness.

I first imported the oldest version of the source for which we have local
mods:

        cd imap-2001a
        cvs import -m 'Import of UW IMAP 2001a' vendor/imap UW IMAP-2001a
        cd .. ; rm -rf imap-2001a

I then created a couple of branches from there, and committed two
different versions of our local patches to those two different branches:

        cvs rtag -b -r IMAP-2001a IMAP-2001a_LOCAL_OPENLDAP1 vendor/imap
        cvs rtag -b -r IMAP-2001a IMAP-2001a_LOCAL_OPENLDAP2 vendor/imap

I checked out each branch, applied the appropriate patch, used `cvs add'
to add a couple new files to each branch, and then committed our changes.
I have verified that our two different external patches are now correctly
living on these two branches.

Here's where the stuff that's likely relevant starts:

I imported the next version of the vendor sources for which we have an
updated patch:

        cd imap-2002.RC6
        cvs import -m 'Import of UW IMAP 2002.RC6' vendor/imap UW IMAP-2002_RC6
        cd .. ; rm -rf imap-2002.RC6

Thanks to some guidance Larry Jones gave several months ago on the list,
I know enough to do a merge of the two vendor versions, to take care of
any structural changes:

        cvs checkout -j IMAP-2001a -j IMAP-2002_RC6 vendor/imap
        cd vendor/imap
        cvs commit -m 'merge vendor IMAP-2001a -> IMAP-2002_RC6'
        cd ../..
        cvs release -d vendor

I have verified that files that were part of the 2001a release but not
part of the 2002.RC6 do *not* show up after the merge if I check out the
IMAP-2002_RC6 release.

I then create a local branch for our mods:

        cvs rtag -b -r IMAP-2002_RC6 IMAP-2002_RC6_LOCAL imap

(note that imap is defined in the modules file, as vendor/imap)

I checked out that branch, applied our local patch, cvs add'ed the two
new files created by the patch, and committed the changes to the local
branch:

        cvs checkout -r IMAP-2002_RC6_LOCAL imap
        cd imap
        patch -p1 < ../../../SOURCES/imap-2002.RC5-KerDAP.patch.20020918
        cvs update # to show what's new/modified
        cvs add src/osdep/unix/KerDAP.h src/osdep/unix/kerdap.c
        cvs commit
        cd ..
        cvs release -d imap

Next I imported the latest vendor release and did a merge of the previous
vendor import and the latest one, to handle any structural changes:

        cd imap-2002c1
        cvs import -m 'Import of UW IMAP 2002c1' vendor/imap UW IMAP-2002c1
        cd ..
        rm -rf imap-2002c1

        cvs checkout -j IMAP-2002_RC6 -j IMAP-2002c1 imap
        cd imap
        cvs update
        cvs commit -m 'merge of vendor IMAP-2002_RC6 -> IMAP-2002c1'

        cd ..
        cvs release -d imap

Now I create a new local branch, rooted off the latest vendor sources:

        cvs rtag -b -r IMAP-2002c1 IMAP-2002c1_LOCAL imap

The next step is where I encountered the problem.  I want to bring the
changes we made on the previous local branch, IMAP-2002_RC6_LOCAL, forward to
this new local branch.  I thought it would be as simple as:

        cvs checkout -r IMAP-2002c1_LOCAL imap
        cd imap
        cvs update -j IMAP-2002_RC6_LOCAL

The problem is, in addition to the 5 changes I expected to see merged
from the older branch (three files modified, two new files), there are two
*other* files that are getting moved forward into the new branch -- both
files are part of the IMAP-2002_RC6 (vendor branch) and IMAP-2002_RC6_LOCAL
(local branch), but they're *not* part of the IMAP-2002c1 vendor import.

Based on my reading of the Cederqvist, the

        cvs update -j IMAP-2002_RC6_LOCAL

should have brought forward *only* the changes made on the branch (two
files added, 3 others modified), and not any other changes.  I did the
merge between the two vendor imports, so why are files that were part of
2002.RC6 "coming back" on a local branch that's rooted off 2002c1?

Also, we've discovered that if I instead do:

        cvs checkout -r IMAP-2002c1_LOCAL imap
        cd imap
        cvs update -j IMAP-2002_RC6 -j IMAP_2002_RC6_LOCAL

I get only the modifications that I expect -- two files added, three
others modified.  The two files that get added when I do the merge the
other way (the way that's shown in section 5.6 of the Cederqvist) don't
appear when I explicitly give the start and end points to merge from.

Any suggestions regarding what the problem might be?  I'm guessing that
something went wrong when I did the merge of the two vendor versions
IMAP-2002_RC6 and IMAP-2002c1, but that's just a guess.

This leads to another (likely dumb) question.  Let's say that the first
import and the local branches I created off that are fine, and the second
import and the local branch I created off it are also fine, but that the
third import and it's local branch are screwed up somehow.

Is there any way to "chop off" the most recent import and any and all
branches rooted off it, and then re-do the import and the branch(es)?
If I have to remove the entire imap directory from CVS and go through
the whole import-and-branch process again (starting over) I can, but
that might be a lot less palatable down the road.

Any tips or wisdom people can provide are much appreciated!

Thanks!

Tim
-- 
Tim Mooney                              address@hidden
Information Technology Services         (701) 231-1076 (Voice)
Room 242-J6, IACC Building              (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164