Background: at my company, we have a Subversion repo which I
frequently import into Mercurial via hgpullsvn. A coworker has created
a rather large patch against the svn repo a few weeks ago which I
tried to merge into the current head using hg. To my great surprise,
the merge changeset was empty which led me to the assumption that said
patch had already been merged into the svn repo (bit by bit, I
thought). I was quite baffled when I found out that this was not the
case at all. After investigating this strange case for a few hours, I
found the problem.


svn x-1
    |
    |
  svn x
    |\
    | +-----------\
    |             |
svn x+1    coworker's patch
    |
   ...
    |
    |
   <A>
    |
    |
   <~A>
    |
    |
   ...
    |
svn current (hundreds of revisions later)

The diagram above shows my situation (top is oldest, bottom is
newest). "svn x" is the revision against which my coworker's patch was
made. At one point I had the patch in my working directory and --
being used to Mercurial where it's easy to take back a commit -- I
accidentally committed the patch to the subversion repository (<A>). I
immediately reverted the commit (<~A>) but history cannot be deleted
so the mistake sits there forever.

Now when I try to merge "coworker's patch" and "svn current" in
Mercurial, apparently revision "<A>" is used as the ancestor instead
of "svn x" (that's what merge --debug says; hg debugancestor correctly
reports "svn x"). The end result is that the entire patch is
completely thrown away without any indication that something went
wrong.

Benoit Boissinot was nice enough to produce a testcase:

hg init
echo a > a
hg ci -Am m
echo b >> a
hg ci -Am m
echo a > a
hg ci -Am m
hg up 0
echo b >> a
hg ci -Am m
hg view
hg merge --debug
cat a

You'll get 'a\n' instead of 'a\nb\n'.

Original message: http://selenic.com/pipermail/mercurial/2008-October/021625.html