Re: Repeated Conflicts

[Paul Sander]

>--- Forwarded mail from address@hidden

>On Thu, Feb 19, 2004 at 01:21:47PM -0800, Paul Sander wrote:
>> Chances are you're using the default common ancestor for each merge.  The
>> 3-way merge algorithm then rediscovers each change made cumulatively on both
>> branches each time.  The solution is to specify the result of the last merge
>> as the common ancestor when you run "cvs update".  For that, you must tag
>> the results of each merge and remember to use that tag for the next merge.

>We are merging only one branch at a time e.g.:

>cd /location/of/release/checkout
>cvs update -kk -j html www . 2>/dev/null
> - This merges changes from the html branch of the www module

>Once this is done, the same conflicts appear as the last time.

>We have attempted to merge (after commiting changes from the above)
>from release to html but the same conflicts still arise.

What's happening is that "cvs update" is doing a 3-way merge, using the
sprout point of the branch as the common ancestor.  The semantics of
a 3-way merge involve applying the differences between the common ancestor
and the contributor branch to the target.  Conflicts occur when changes
appear in the same places on both branches.  Because CVS doesn't remember
the results of past merges, the results of past merges become conflicts
in future merges.

To fix this, you must introduce a memory of past merges.  One way to do
that is to apply a tag to the result of each merge, and use it as the
common ancestor for the next merge.

>If I'm understanding your suggestion correctly I'd do something like:

>cvs update -kk -j html www .
>(fix conflicts, etc.)
>cvs commit -m "merged from html"
>cvs tag -r merged_into

Omit the -r and apply the tag to the committed versions.

>Later when doing another merge after the above has happened:
>cvs update -kk -j html -r merged_into .

Change the -r to -j to specify that you really mean a 3-way join.

>This however doesn't quite make sense to me.

I hope this clears it up.

>> --- Forwarded mail from address@hidden
>> We now have developers working in multiple branches.
>> When ready I merged their branches into a release branch.
>> When merging I'm finding myself fixing the same conflicts over and
>> over.
>> I have a feeling I'm missing something simple in our process. Any 
>> enlightenment?
>> --- End of forwarded message from address@hidden

>--- End of forwarded message from address@hidden