[PATCH STABLE] icasefs: abort update, if added/removed files in working causes case folding collision

[Matt Mackall]

On Thu, 2012-04-05 at 17:31 +0900, FUJIWARA Katsunori wrote:
> At Wed, 04 Apr 2012 11:47:00 -0500,
> Matt Mackall wrote:
> > 
> > On Wed, 2012-04-04 at 18:35 +0900, FUJIWARA Katsunori wrote:
> > > # HG changeset patch
> > > # User FUJIWARA Katsunori <foozy at lares.dti.ne.jp>
> > > # Date 1333530684 -32400
> > > # Branch stable
> > > # Node ID a2faca19606fece6bab91d0fa7f9b421b2d98cc9
> > > # Parent  4d875bb546dc03db33630f5388d7e04939c386a0
> > > icasefs: abort update, if added/removed files in working causes case folding collision
> > 
> > Doesn't this do the trick:
> > 
> > diff -r 1d8eab6dfe65 mercurial/merge.py
> > --- a/mercurial/merge.py	Tue Apr 03 22:02:04 2012 +0200
> > +++ b/mercurial/merge.py	Wed Apr 04 11:45:59 2012 -0500
> > @@ -568,7 +568,7 @@
> >          action = []
> >          folding = not util.checkcase(repo.path)
> >          if folding:
> > -            _checkcollision(p2, branchmerge and p1)
> > +            _checkcollision(p2, wc)
> >          if not force:
> >              _checkunknown(repo, wc, p2)
> >          action += _forgetremoved(wc, p2, branchmerge)
> 
> If 'wc' is used always, the linear updating case, which you pointed
> out for my past post for d550168f11ce, causes abort for case folding
> collision.

The answer to my original question:

'What happens on linear updates? Is it correct?'

seems to be.. 'we ignore real case collisions' and 'no'.

In other words.. _this bug_. Let me try rephrasing my original question:

'What is special about a branch merge that makes it want collision
detection but other merges don't?'

I thought you were going to fix this:

'So, I'll post with enhancement of new test to check also merging in
linear update.'

http://www.selenic.com/pipermail/mercurial-devel/2011-December/036320.html

But v4 didn't change it.

Also, why do we use p1 instead of wc? The function _checkcollision has
wctx in its prototype, but isn't getting a working context. And the
working context is obviously the right thing to be looking at.

And then there's question 2:

>     If Alice moves 'a' to 'A' and then Bob pulls and updates while he
>     has edits to 'a', will he now have a modified 'A'?

The answer is that right now, without my patch, an update clobbers
'a' (bad!) and branch merge aborts (better, but not perfect). With my
patch, they both abort, which seems an improvement.

Unfortunately, what doesn't work with my patch is that if I rename 'a'
to 'A', commit, then try to go backwards, it fails. So it seems we need
some rename-awareness in _checkcollision. On the other hand, without my
patch, it will clobber newly-added files that collide with old files
when going backwards.

> # http://www.selenic.com/pipermail/mercurial-devel/2011-December/036302.html
> 
> In addition to it, 'removed in working context' case can not be
> detected in this way, because 'workingctx.__iter__()' ignores removed
> files.

??

A removed file and a non-removed file with case-colliding names can
coexist in the dirstate and won't collide on the filesystem.

Also, your latest patch seems to only deal with dirstates 'r' and 'a',
but ignores 'm' and 'n'!

-- 
Mathematics is the supreme nostalgia of our time.