[cvsnt] Mergepoint issues on 2.5.0.3 b2382

[Tony Hoyle]

Harrison, Andy wrote:
> As I understand the above, it's the same as the first scenario in my
> previous mail. I'm interested in the changes that they did not merge.
> Did they edit the file to remove the merged code? Did they do a update
> -C on certain files? Or did they simply not commit certain files. It
> would be my expectation that if either the second or third option were
> performed, then since no commit took place on those files, no mergepoint
> would have been stored. In this case on merging back to A, the branch
> point would have been used as there is no merge point. Is this correct?

They edited the file or even possibly got both versions using winmerge 
and merged manually (winmerge has its own merging process) after using 
update -j to generate the mergepoint.

I've had scenarios where two branches are different enough that you 
merge into one, copy back the old one and make the changes manually.. 
having the mergepoint means you don't have to do that more than once. 
It's the exception rather than the rule though.

> This leads me to assume that they must have done the first action, i.e.
> merged the file and then manually edited the file in order to remove
> parts (or all) of the merge. In my opinion (and I guess this is where
> you disagree), these changes are edits that have been performed of
> branch B, and so in merging B->A, these edits should be included in the
> merge.

It's a question of expectation - what the user wanted was clear enough - 
just a small number of changes made to branch B merging back into branch 
A.  That's rather hard to achieve automatically (you can't even define 
'change' in a non-ambiguous way when merge operations are involved.. 
humans tend to think of modifying stuff to resolve conflicts as 'not a 
change' when the code thinks that it is).

> A similar scenario would be if the user had merged A->B and committed
> all of the changes. Then they edit the files on B to remove some of the
> changes made in the merge, and commit. They then merge B->A. Would you
> expect those edits made between the two merges to be merged back to A or
> not?

I can think of scenarios where they would expect them not to be (see the 
problem with defining 'change' above).  The main difficulty though 
arises with the revision involved in the merge, and how you split off 
'wanted' and 'unwanted' changes.  My current understanding is that's 
impossible - it's all or nothing (and there are good reasons for both).

Such things are often process issues, hence march hare's recommendation 
of promotional branches - everything's one way and there's no ambiguity 
what should be happening.  That's not to say there aren't legitimate 
arguments for doing it in other ways, but it's harder to support.

Tony