[PATCH STABLE] icasefs: abort update, if added/removed files in working causes case folding collision
foozy at lares.dti.ne.jp
Mon Apr 9 07:06:52 CDT 2012
At Thu, 05 Apr 2012 14:26:21 -0500,
Matt Mackall wrote:
> > > 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)
> 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.
I want some suggestions about my work.
At first, I added below logic to collision detection:
- check rename/copy if collision is detected BETWEEN working and
if colliding file in target context is copy of collided file in
working context, collision can be ignored: colliding file maybe
rename of collided one, because collision is not detected IN
target context and it ensures that collided file does not exist in
this is achieved by result copies.pathcopies(),
Then, it is assumed that there are two revisions in linear history
#1: has 'a' and 'b'
#2: has 'A' renamed from 'b', and 'C' renamed from 'a'
On updating from #1 to #2, collision between 'a'@#1 and 'A'@#2 is
recognized as not ignorable collision, because 'A'@#2 is not copy of
'a'@#1, even though it can be renamed to 'C'@#2 safely.
Should I check whether files copied from 'a'@#1 exist in #2 or not ?
In another case, it is also assumed that there are two revisions:
#1: has 'a' and 'b'
#2: has 'A' renamed from 'b', but no 'a' which was removed
On updating from #1 to #2, there is no file copied from 'a'@#1 in #2,
so this will be recognized as not ignorable collision, even though 'a'
is clean in working context.
If 'a' is modified in working context in above case, aborting by
collision seems to be reasonable. But should I abort updating after
confirmation like below ?
local changed 'a' which remote deleted
use (c)hanged version or (d)elete?
# abort updating if 'changed' is chosen
Perhaps, should I examine case-folding collision not at current point,
but after manifest merging ? It seems to figure out renaming, coping,
collision between modifying and removing, and so on: all about what we
want to know for collision detection.
[FUJIWARA Katsunori] foozy at lares.dti.ne.jp
More information about the Mercurial-devel