[PATCH 5 of 8] Fix for issue 750 (Revisions with case-only renames ...)

[Matt Mackall]

On Thu, 2008-05-01 at 21:30 +0100, Paul Moore wrote:
> 2008/5/1 Matt Mackall <mpm at selenic.com>:
> >  > Fix for issue 750 (Revisions with case-only renames ...)
> >  >
> >  > This patch ensures that case-only renames are merged correctly by sorting the
> >  > merge actions case insensitively on filename, and then making sure removes
> >  > sort before fetches (so that the remove of the old case does not remove the
> >  > newly-fetched new case).
> >
> >  Is this actually still necessary? The new merge code stashes a copy of
> >  every file to be merged before anything else happens so that file merges
> >  can be retried.
> 
> It seems to be, to me - at least the bug is still present in crew, and
> as far as I can tell, it's because, given a file a.txt and a rename
> a.txt -> A.TXT, the code does a get of A.TXT first, then the remove of
> a.txt. And on a case-insensitive system, that second step, the remove,
> quite happily removes the A.TXT that you've just retrieved. The cause,
> fundamentally, is that os.remove('a.txt') will remove A.TXT, and you
> can't stop it doing so, so you have to avoid giving it the chance.
> 
> On the other hand, I'm not 100% sure what you mean by "the new merge
> code" - I've been looking solely at crew, is that what you're
> referring to, or is there even newer code I haven't seen?

This:

http://hg.intevation.org/mercurial/crew/file/626cb86a6523/mercurial/merge.py#l271

..will protect us when the file actually gets merged.

In the non-merge case, it seems that simply doing all the removes before
all the gets is sufficient?

-- 
Mathematics is the supreme nostalgia of our time.