The proposed solution sounds useful, though in this specific case, the
changes were so small that the merge was trivial to do - I was more
curious to understand the meaning of what I'm seeing. 

Anyway, thanks everybody.

Daniel

Avi Bryant <avi at beta4.com> wrote:
> 
> On Fri, 8 Aug 2003, Daniel Vainsencher wrote:
> 
> > I loaded the RB from SM. Fixed various KCP issues. Then loaded MC, then
> > loaded the previous RB .mcv. I got warned about spurious conflicts,
> > proceeded.
> 
> Oh, ok.  This means that the two versions didn't actually share a common
> ancestor (which makes sense, since it sounds like you didn't start from an
> .mcv file at all).  Merging in this case is going to be a bit odd.  What
> it does is treats the empty package as the common ancestor - that is, it
> pretends that these two versions (the one in your image and the one you're
> merging) both *independently* made all of the changes necessary to bring
> the empty package to their current state - and then tries to merge them.
> Since, compared to the empty package, they have both made a lot of
> extremely similar changes, you're bound to get some odd conflicts...
> however, why class extensions in particular would be singled out I have no
> idea.
> 
> What you actually want is a way of just pointing to a .mcv made from the
> SM version and saying "this is an ancestor of the code that's in the
> image".  That would make future merges work a lot better.  There's no UI
> for doing this currently, although it would be doable programmatically...