root-ids changing for some merges (was Re: [Merge] lp:~abentley/bzr/merge-into-empty into lp:bzr)

[vila]

>>>>> Aaron Bentley writes:

<snip/>

    > The code in TreeTransform.fixup_new_roots seemed more suitable
    > than the code in Merger.fix_root, so I've switched to
    > fixup_new_roots and deprecated fix_root.

    > There is some behavioural difference between the
    > two. fixup_new_roots does not generate a conflict if a new root is
    > added and the old root is not deleted.  It happily merges the
    > contents of the two roots.  In such cases, the new root wins,
    > whereas fix_root would have the old root win.

The drawback that I just realized is that it breaks 'merge -r0..nn
../unrelated-branch' by forcing the new root which in turn trigger a
rename for all existing children of the old root (try merging 2.3 into
trunk for a reproducing case encountered while fixing bug #805809).

It's late here and I haven't a fix so far but I don't think we should
release 2.4b5 without fixing this as the consequences sound a bit scary.

While this may sound like an unusual use case, it's more than usual for
UDD.

    > Still, the new behaviour is in keeping with Merge's tendency of
    > letting OTHER win in the case of ambiguity.

It shouldn't apply to root-ids but can be special-cased for the empty
*branch* which should also cover your case for the empty *tree*.

    > And reducing duplication between fixup_new_roots and fix_root is
    > also a win.

    Vincent