[cvsnt] Re: Branch merging - this seems wrong...

[Tony Hoyle]

Tony Eva wrote:
> Yes - but I don't see how that's relevant. I would contend that when I
> commit after the merge from HEAD to b1, I have effectively declared that
> b1 now contains the merged results to my satisfaction.  CVS should take

But you have not said that b1 contains HEAD - in fact they may be very different.

> I agree.  However, after a merge A->B, B contains a combination of
> information from A and information from B, and by committing the merge,
> I declare that I am happy with the results.  At this point CVS should
> assume that B has all of A's information *up to the point of the merge*,
> and that a subsequent merge B->A only needs to take into account any
> changes on A and B that happened after the merge.  If there were none

It doesn't - it needs to take into account all changes in B that happened 
*before* the merge too.

> It's hard to see how changes could be lost, assuming that all files has
> been committed prior to the merge?  Of course, if someone was so daring
> as to perform a merge on top of *uncommitted* changes, then they really
> should have known better :-)

It's very easy.

Branch
Make changes in B
Merge A->B
Merge B->A

If you use the merge point the changes in the second step are lost.

> - in the changeset scenario, however, bidirectional merges are the norm.

Not at all - you wouldn't normally merge individual files from the main trunk 
once it's been branched...  It's still all unidirectional from the branched 
files to back to the trunk once the change as been made.  If you bidirectional 
merges you don't have a proper changeset since you haven't clearly separated 
the changes.

Normally this wouldn't be handled by branches at all - you'd do it using the 
builtin support using bug IDs or by either cooperative or reserved edits.

Tony