I thought I had this strainght but apparently not so if someone can help me
figure it out I'd appreciate it! We're using release 1.10 (Halibut)
We have (or are planning to have) a branch to hold patches to a release (for
this example, branch tag = patches). As patches are committed to the branch, we
want to merge them back to the trunk in order to keep the trunk up to date. So
that we don't get conflicts each time we do this, we have a tag on the branch
(patches_last_merge) which we move after each merge. This works fine until we
want to do the fix differently on the trunk as opposed to the branch.
eg. on the branch, the file f1 contains:
Line 1
Line 2 on the branch
and on the trunk it contains:
Line 1
Line 2 on the trunk
Now, we move the tag on the branch so that it's pointing to the latest revision
on the branch:
cvs tag -F -r patches patches_last_merge f1
Just to see what happens:
cvs update -A
cvs update -j patches_last_merge -j patches f1
As expected, f1 doesn't change because the tag is on the head of the branch
So, back to the branch, add another line (Line 3), commit it and merge it back
to the trunk as above. This gives conflicts, thus:
Line 1
<<<<<<< f1
Line 2 on the trunk
=======
Line 2 on the branch
Line 3
>>>>>>> 1.1.2.2
when all I expected was the automatic merging of "Line 3"!
cvs diff -r patches_last_merge -r patches f1
gives the expected output:
diff -b -c -r1.1.2.1 -r1.1.2.2
*** f1 2000/06/20 00:40:32 1.1.2.1
--- f1 2000/06/20 00:55:48 1.1.2.2
***************
*** 1,2 ****
--- 1,3 ----
Line 1
Line 2 on the branch
+ Line 3
and I thought that all the merge was doing was taking a diff between
patches_last_merge and patches and applying it to the working copy. What am I
missing here?
Lastly, if I resolve the conflicts, move the tag, then make a further change on
the patches branch, the subsequent merge to the trunk works as expected.
Yours in confusion,
--
"Everyone is ignorant, only on different subjects." (Will Rogers)
Brian Collins
Triple G Asia Pacific
http://www.tripleg.com