[PATCH 4 of 4 mergedriver] merge: move almost all change/delete conflicts to resolve phase (BC) (API)
Yuya Nishihara
yuya at tcha.org
Sun Dec 6 06:23:09 CST 2015
On Sat, 05 Dec 2015 21:49:21 -0800, Pierre-Yves David wrote:
> On 12/05/2015 06:51 PM, Matt Harbison wrote:
> > On Sat, 05 Dec 2015 04:49:41 -0500, Yuya Nishihara <yuya at tcha.org> wrote:
> >
> >> On Thu, 03 Dec 2015 22:19:44 -0500, Matt Harbison wrote:
> >>> Not sure why, but I'm seeing this on Windows:
> >>>
> >>> --- c:/Users/Matt/Projects/hg/tests/test-subrepo-missing.t
> >>> +++ c:/Users/Matt/Projects/hg/tests/test-subrepo-missing.t.err
> >>> @@ -64,8 +64,12 @@
> >>> $ hg up 0
> >>> remote changed .hgsubstate which local deleted
> >>> use (c)hanged version or leave (d)eleted? c
> >>> + subrepository subrepo diverged (local revision: , remote revision:
> >>> 07f494440405)
> >>> + (M)erge, keep (l)ocal or keep (r)emote? m
> >>> + 0 files updated, 0 files merged, 0 files removed, 0 files unresolved
> >>> 1 files updated, 0 files merged, 0 files removed, 0 files unresolved
> >>> $ hg st
> >>> + M .hgsubstate
> >>> $ ls subrepo
> >>> a
> >>>
> >>> I'd write it off because you mention not dealing with .hgsubstate
> >>> conflicts below, but the test runs fine on Linux. I didn't try OS X. I
> >>> can file a bug if it isn't an issue you are aware of/have a ready fix
> >>> for.
> >>
> >> The problem is that wctx.substate can be stale after batchget or
> >> batchremove,
> >> and it is loaded before applyupdates() on Windows.
> >>
> >> --- a/mercurial/merge.py
> >> +++ b/mercurial/merge.py
> >> @@ -1056,6 +1056,11 @@ def applyupdates(repo, actions, wctx, mc
> >> progress(_updating, z, item=item, total=numupdates, unit=_files)
> >> updated = len(actions['g'])
> >> + # not sure this is right, but wctx can have stale cache after
> >> + # batchremove/updates, so we have to do something like this:
> >> + if removed or updated:
> >> + wctx = repo[None]
> >> +
> >> if [a for a in actions['g'] if a[0] == '.hgsubstate']:
> >> subrepo.submerge(repo, wctx, mctx, wctx, overwrite)
> >
> > Fixes it for me, but I have no idea if it is right either. I'll write
> > up the bug like Pierre-Yves asked so we can keep track of it.
>
> Nice, please, send a proper patch and I'll take it.
This breaks the other tests. Perhaps submerge() for actions['g'] actually want
stale wctx.substate because it is the fixing process of batchget?
I seems the real problem is submerge() is called twice, for 'g' and 'dc'.
The following patch is the dumbest implementation to show and apparently fix
this problem.
--- a/mercurial/merge.py
+++ b/mercurial/merge.py
@@ -1038,6 +1038,8 @@ def applyupdates(repo, actions, wctx, mc
numupdates = sum(len(l) for m, l in actions.items() if m != 'k')
+ wctx.substate # XXX to reproduce issue4988 on Unix
+
if [a for a in actions['r'] if a[0] == '.hgsubstate']:
subrepo.submerge(repo, wctx, mctx, wctx, overwrite)
@@ -1137,19 +1139,27 @@ def applyupdates(repo, actions, wctx, mc
# premerge
tocomplete = []
for f, args, msg in mergeactions:
+ if f == '.hgsubstate':
+ continue
repo.ui.debug(" %s: %s -> m (premerge)\n" % (f, msg))
z += 1
progress(_updating, z, item=f, total=numupdates, unit=_files)
- if f == '.hgsubstate': # subrepo states need updating
- subrepo.submerge(repo, wctx, mctx, wctx.ancestor(mctx),
- overwrite)
- continue
audit(f)
complete, r = ms.preresolve(f, wctx, labels=labels)
if not complete:
numupdates += 1
tocomplete.append((f, args, msg))
+ # premerge for .hgsubstate: 'cd' and 'dc' actions are prompted before;
+ # do submerge only for 'm'
+ for f, args, msg in actions['m']:
+ if f != '.hgsubstate':
+ continue
+ repo.ui.debug(" %s: %s -> m (premerge)\n" % (f, msg))
+ z += 1
+ progress(_updating, z, item=f, total=numupdates, unit=_files)
+ subrepo.submerge(repo, wctx, mctx, wctx.ancestor(mctx), overwrite)
+
# merge
for f, args, msg in tocomplete:
repo.ui.debug(" %s: %s -> m (merge)\n" % (f, msg))
More information about the Mercurial-devel
mailing list