[PATCH 1 of 5 RFC] tests: show added/modified/removed files when logging repos converted from bzr
Matt Harbison
mharbison72 at gmail.com
Sat Aug 11 03:00:39 UTC 2018
On Sat, 28 Jul 2018 10:59:12 -0400, Yuya Nishihara <yuya at tcha.org> wrote:
> On Sat, 28 Jul 2018 10:37:37 -0400, Matt Harbison wrote:
>>
>> > On Jul 28, 2018, at 3:05 AM, Yuya Nishihara <yuya at tcha.org> wrote:
>> >
>> >> On Fri, 27 Jul 2018 14:14:27 -0400, Matt Harbison wrote:
>> >> On Fri, 27 Jul 2018 14:10:08 -0400, Matt Harbison
>> <mharbison72 at gmail.com>
>> >> wrote:
>> >>
>> >>> # HG changeset patch
>> >>> # User Matt Harbison <matt_harbison at yahoo.com>
>> >>> # Date 1531499586 14400
>> >>> # Fri Jul 13 12:33:06 2018 -0400
>> >>> # Branch stable
>> >>> # Node ID 3da5d60bf6e7ad121cea897e2f59846007f3cc9f
>> >>> # Parent 0f948d821fe7e5ed18e6106c162375a11e8b0546
>> >>> tests: show added/modified/removed files when logging repos
>> converted
>> >>> from bzr
>> >>
>> >> I know we're in the middle of a freeze, but I didn't get a chance to
>> >> figure out this memctx status filtering. I'm on vacation, so the
>> chances
>> >> of me getting back to it are quite slim. Since it affects more than
>> a
>> >> corner case with convert[1], and it permanently affects the repo,
>> it's
>> >> probably worth someone who understands the status calculating to
>> take a
>> >> run at it.
>> >>
>> >> [1]
>> >>
>> https://www.mercurial-scm.org/pipermail/mercurial-devel/2018-July/118907.html
>> >
>> > Does the hack in the previous thread solve your problem?
>>
>> IIRC, the hack you posted just printed a message when the problem
>> occurred- it didn’t try to fix it. I remember running it, and I think
>> the message came out a couple of times. (I thought far fewer times
>> than the number of commits that I had to hack to fix up, but it’s
>> possible that this is a cascading problem.) I don’t recall if it
>> printed in the problem *.t test in this series.
>
> Really. I saw several hash changes in test outputs including
> test-convert-bzr-merges.t, so I thought it would catch at least a certain
> type of manifest mis-reuse. Maybe there would be the other ones.
>
> diff --git a/mercurial/localrepo.py b/mercurial/localrepo.py
> --- a/mercurial/localrepo.py
> +++ b/mercurial/localrepo.py
> @@ -2028,6 +2028,7 @@ class localrepository(object):
> # reuse an existing manifest revision
> mn = ctx.manifestnode()
> files = ctx.files()
> + self.ui.debug('reusing known manifest')
> elif ctx.files():
> m1ctx = p1.manifestctx()
> m2ctx = p2.manifestctx()
> @@ -2064,16 +2065,26 @@ class localrepository(object):
> raise
> # update manifest
> - self.ui.note(_("committing manifest\n"))
> removed = [f for f in sorted(removed) if f in m1 or f
> in m2]
> drop = [f for f in removed if f in m]
> for f in drop:
> del m[f]
> - mn = mctx.write(trp, linkrev,
> - p1.manifestnode(), p2.manifestnode(),
> - added, drop)
> + # if no files actually changed, try hard to detect
> unmodified
> + # manifest entry caused by error in memctx or
> workingcommitctx
> + # with bad copy information
> + if (changed or removed
> + or m1.diff(m, scmutil.matchfiles(self,
> ctx.files()))):
> + self.ui.note(_("committing manifest\n"))
> + mn = mctx.write(trp, linkrev,
> + p1.manifestnode(),
> p2.manifestnode(),
> + added, drop)
> + else:
> + self.ui.debug('reusing manifest form p1
> (inconsistency '
> + 'found in %r)\n' % ctx)
> + mn = p1.manifestnode()
> files = changed + removed
> else:
> + self.ui.debug('reusing manifest from p1 (no file
> change)\n')
> mn = p1.manifestnode()
> files = []
I applied this, adjusted the 3 'reusing' lines to ui.status(), reconverted
from bzr, and then converted that from hg -> hg. I also printed p1.node()
to have some idea of where it was when grepping.
For the bzr -> hg leg, grepping the output for 'reusing' revealed 7
instances of "reusing manifest from p1 (no file change)". When I
converted that to hg again, I got 13 instances of that line. I wasn't
expecting the number to change. The first two instances lined up with
identical p1 hashes. The next 5 had different p1 hashes, but they're the
same commit, demonstrated by comparing 'convert_source'. The rest are
commits that weren't flagged in the bzr -> hg convert.
I ran `hg log -r $bad --debug` on the first divergent changeset in these
two repos, and everything matches but the changeset hash. I ran `hg
debugindex -m` on both repos and diffed. That output is identical, well
past the divergence point. The output of `hg debugindex -c` differs on
the divergent changesets, even though the files listed with `log --debug`
match. Not sure what that means.
Finally, I reconverted the original production hg repo (originally
converted with ~3.7.1) using a vanilla 4.6.1. The result of this is
identical to the output of the above hg -> hg conversion with your hack.
So I guess the story here is that in trying to illustrate the problem I
was having via a simple test, I swerved into a different problem with the
manifest. It seems that your hack is worth
submitting, because it helps a particular problem. My problem seems
changelog related.
The previous RFC series[1] gets the conversion further along than this
manifest node hacking, avoids early changelog differences, and it diverges
in the second half of an octopus merge. But it clearly isn't correct,
given some of the test failures.
Since I redirected the convert output to a file for the bzr -> hg run, I
now see there are a couple of messages related to missing files, which
correspond to files missing from the `hg log -r $octopus_fixup --debug`
output:
warning: can't find ancestor for
'Linux/Uboot/XC8600/uboot_bsp/devicetree_externalfpgaconfig.dts' copied
from 'Linux/Uboot/XC8600/uboot_bsp/devicetree_serialpromfpga.dts'!
warning: can't find ancestor for
'Linux/Uboot/XC8600/uboot_bsp/settings_externalfpgaconfig.bsp' copied from
'Linux/Uboot/XC8600/uboot_bsp/settings_serialpromfpga.bsp'!
That doesn't happen with 3.7.1, from the original conversion.
[1]
https://www.mercurial-scm.org/pipermail/mercurial-devel/2018-July/119438.html
More information about the Mercurial-devel
mailing list