Unexpected merge conflict - bug maybe?

[Chuck . Irvine]

I would appreciate help understanding how the merge conflict 
that I am about to describe can logically happen. (I am 
using cvs 1.11).

The conflict involves two branches, BRANCH, and a sub-branch 
of BRANCH, SUB_BRANCH. So far, here's the history of the 
two branches. 

- Created SUB_BRANCH form BRANCH at stable build point

cd <top level BRANCH dir>
cvs tag BRANCH_BUILD_TAG_1
cvs tag -b SUB_BRANCH

- Merged changes on BRANCH to SUB_BRANCH 

cd <top level BRANCH dir>
cvs tag BRANCH_TAG_2
cd <top level SUB_BRANCH dir>
cvs -q update -j BRANCH_TAG_1 -j BRANCH_TAG_2
<resolve conflicts>
cvs -q ci -m "merged from trunk to branch" 
<every thing went ok so far>

- Merged changes on BRANCH to SUB_BRANCH a second time

cd <top level BRANCH dir>
cvs tag BRANCH_TAG_3
cd <top level SUB_BRANCH dir>
cvs -q update -j BRANCH_TAG_2 -j BRANCH_TAG_3

Here is where I got the unexpected conflict: I got a 
merge conflict on a file that had never been modified on 
SUB_BRANCH. I checked the history of the file on BRANCH. 
It has undergone just one revision since the creation of 
SUB_BRANCH. Can anyone explain how this might happen?! 

Trying to understand this, a question arose - when performing 
the merge from BRANCH_TAG_1 to BRANCH_TAG_2, how does CVS determine
what constitutes a merge. That is, how does it know whether any of 
the differences being applied conflict with any changes that may have 
been made on SUB_BRANCH? Does CVS it compare the applied differences 
with all of the changes that have been made to SUB_BRANCH since it's 
creation? Correct?

Sorry I got a little long winded. Thanks for any help you might
be able to provide.

Chuck