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

[FUJIWARA Katsunori]

At Thu, 05 Apr 2012 14:26:21 -0500,
Matt Mackall wrote:
> 
> 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.

Thank you for detailed explanation, and sorry I misunderstood your
suggestion: I thought "modification should follow renaming in above
linear updating case."

> 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.

Maybe, I though just about collision detection in branch merging.

> 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.

Yes, you are right. I just worried about confusion of users: there is
still the file which is treated as same as removed file on icasefs.

# users can't go backwards easily in such case, too

I have no objection to merge similarly in both branch merging and
linear update merging.


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

This comes from my misunderstanding described above.


I'll try to achieve rename-awareness in _checkcollision.

----------------------------------------------------------------------
[FUJIWARA Katsunori]                             foozy at lares.dti.ne.jp