On Wed, Aug 09, 2000 at 11:48:43AM -0700, Keith Beattie wrote:
> Hi all,
>
> I don't entirely understand why if you merge a branch to the trunk twice and
> don't use 2 -j args for the second merge, the changes brought in with the
> 1st merge will sometimes show up as conflicts. I'd expect that CVS would
> recognize that for each such change that is already in the trunk, a warning
> or something would be printed rather that it showing up sometimes as a
> conflict
That's just it. CVS doesn't know where you have merged and where you
haven't. It also can't look at a piece of code and decide what's correct.
Humans have to do this. For Instance suppose two developers are making
these changes to a text file:
orig file excerpt:
###### Start######
The 2 things that are important here are:
peanut butter
jelly
###### End########
Now on branch1 a developer makes this change:
###### Start######
The 3 things that are important here are:
peanut butter
jelly
cvs
###### End########
Now on the mainline a developer makes this change:
###### Start######
The 3 things that are important here are:
peanut butter
jelly
toe-jam
###### End########
Now when I do a merge from the branch into mainline, cvs has to give a
merge warning on the first line...because it cannot tell why / how the
change was introduced. CVS has no apriori knowledge of what is correct
and what is incorrect. It just knows that 2 changes where made
from the original version, and although the changes look the
same they might actually be incompatible.
While you know there not incompatible because of the nature of what
you are doing....
>
> This actually is a simple case of what I'm experiencing because we have a
> rather complicated collection of branches which can (unless we are very
> careful) lead to the same set of changes being in both the source and target
> of a merge. In this situation we face many "false" conflicts that although
> are easy to resolve, we'd like to avoid them entirely.
>
> Any insight for me out the?
Use the 2 arg -j merge option. That's what it is there for....
In fact I would seriously think about creating a standard procedure
that when I do a merge into a mainline I lay a tag from where
I merged from. Just for the situation that you might want to merge again.
If I were you I would create a standard merge tool that did as much
as is possible for you( like laying the tags )...
donald
>
> Thanks,
> ksb
>
>
