[PATCH 1 of 5 RFC] tests: show added/modified/removed files when logging repos converted from bzr

[Matt Harbison]

On Fri, 10 Aug 2018 23:00:39 -0400, Matt Harbison <mharbison72 at gmail.com>  
wrote:

> 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

I finally figured out what's going wrong, and how to fix it, but I'm  
unclear on the *why*.  I also re-ran the conversion with 3.7.1, and now  
see the above warnings.  I must have missed them in the wall of text when  
converting the first time.

The problem is that since 216fa1ba9993, the source repo has been passing a  
set of files clean against p2 to the sink.  But only for hg sources.  If I  
unconditionally substitute an empty set (or update to the parent of  
216fa1ba9993), the changelog problems go away, and I hit the later  
manifest issue for which I was able to create a test[1].  The commit makes  
it sound like the divergence is unintentional, so it sounds like the hg ->  
hg conversion where the changelog is different is wrong?

Sadly, I haven't been able to create a simple test for this changelog  
divergence yet.  The graph in the production repo (i.e. the initial bzr ->  
hg conversion) related to the divergent file entry in the changelog is:

$ hg log -r '((follow("scripts/busybox/busybox")) & ancestors(259)) + 259  
+ ancestor(258,145)' -G -Tcompact
o    259:258,145   3b73ac59a3dd   2016-12-02 15:44 -0500   dorr
|\     Merged down 4K from project trunk.
| :
o :  145   11b13dc01078   2016-12-01 17:58 -0500   msteiner
: :    04K: Other, Moved busybox to scripts directory.
: :
o :  96   d7a5d6cabef2   2016-10-26 15:12 -0400   dpalmerton
:/     02Q: Feature Added root filesystem source to source control.
:
o  95   ac2a46a295b6   2016-10-21 18:04 -0400   pbolin
|    02P: Other, fixed LIO HPS interface deleting task ID zero upon  
failure to init.
~

The file was added in 96, renamed in 145, and then some other stuff was  
merged into it at 259.  So it seems like pretty standard stuff, and I'm  
not sure what is special about this file.

Like the manifest divergence below, I assume this is a problem for more  
than just bzr conversions.  I probably won't spend too much more time on  
it because my goal was to preserve the original hashes, and I think I  
figured out how to do that.  But if anyone wants to throw code or ideas at  
this, I'd be happy to try them.

[1]  
https://www.mercurial-scm.org/pipermail/mercurial-devel/2018-August/120837.html