Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
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