[cvsnt] Mergepoint issues on 2.5.0.3 b2382

[Gerhard Fiedler]

Andreas Krey wrote:

>> If in the merge A->B you had discarded some/most changes as being 
>> irrelevant, committed, then done some more work on branch B then the 
>> merge back must not use 1.2 since 1.2 is not the logical ancestor
> 
> True. But when you don't actually bring in everything from 1.2 then
> there should not be a merge arrow for that action in the first place.

That depends. Maybe the same functionality has been added differently on
the branch and on the trunk. (Say both code lines needed to buffer/queue
some event that previously was handled directly, for different reasons.)
Obviously when you merge the code, you throw away one of the two
implementations (or both, and create an equivalent third).

Merging (as I see it) is not "putting every code that's in both code lines
into one", it's "making the code do everything that's done in both code
lines, in a way that makes sense in the light of the changes in both code
lines". Which may result in substantial code changes in one or both code
lines during the merge.


In any case, there seem to be scenarios where merging back-and-forth isn't
safe; the disagreement is which these are exactly. There is a solution
(unidirectional merge, with a branch copy at the end) that provides all the
benefits without the dangers of running such back-and-forth merges. I fail
to see the actual problem :)

Gerhard