On 2007-05-30 14:56, Richard Lowe <[EMAIL PROTECTED]> wrote:
> Mike Kupfer wrote:
>> I spent a little time review Mercurial's open issues list
>> (http://www.selenic.com/mercurial/bts/) [...]
>
> I'm not (at a quick glance) seeing the issue we have with merges
> picking the wrong ancestor in the case of backouts here, while
> ancestor contents are identical (and thus the merge is non-toxic)
> having to merge changes to files one never touched certainly
> increases the chance of mismerge.
I think I've missed the relevant thread bits.
Can you try to write a minimal list of steps to reproduce this?
To show the merge-which-shouldn't-happen, you can try making a minimal
workspace with one or two files, clone it a few times, make changes
which are backed out in one of them, and try merging with:
env HGMERGE=false hg merge
If you are sure that there should be *no* conflicting hunks in the
changesets merged, this will trigger a merge failure if hg(1) tries
to manually merge even a single file...
With something like a list of steps to reproduce this, we can start by
writing a test case for mercurial/tests/... push it to the developers
of Mercurial, and see what they feel/know about it.
Regards,
Giorgos
_______________________________________________
tools-discuss mailing list
[email protected]
