[PATCH STABLE] icasefs: abort update, if added/removed files in working causes case folding collision
foozy at lares.dti.ne.jp
Fri Apr 6 01:12:15 CDT 2012
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.'
> 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
More information about the Mercurial-devel