hg convert changes a revision's node ID for an unknown reason

Matt Mackall mpm at selenic.com
Sun Jun 26 21:39:11 CDT 2011


On Sun, 2011-06-26 at 21:56 +0200, Mads Kiilerich wrote:
> Peter Hosey wrote, On 06/26/2011 05:33 AM:
> > On Jun 25, 2011, at 20:28:54, Augie Fackler wrote:
> >> On Jun 25, 2011, at 10:24 PM, Peter Hosey wrote:
> >>> On Jun 25, 2011, at 20:22:34, Augie Fackler wrote:
> >>>> There's also another potential wrinkle: convert stores source information in extra, which will necessarily change all the hashes.
> 
> As far as I know that is controlled by convert.hg.saverev - which 
> defaults to False for the same reason.
> 
> >>> That's what I thought, but the hashes are unchanged up to r182. And the extra information would be shown in hg log --verbose, wouldn't it? It's not there in the output I showed for both r183s.
> >> Hm, this is surprising to me. Can you give me a link to the source repo and command to run so I can investigate tomorrow?
> > I will.
> >
> >> No, extra doesn't show in log --verbose. It *does* show in log --debug though.
> > Ah. I thought I was missing something there.
> >
> > Here's that output:
> >
> > <?xml version="1.0"?>
> 
> Note that the xml format is far from being native and authoritative in 
> Mercurial.
> 
> ".../contrib/dumprevlog .../.hg/store/00changelog.i" is more detailed 
> and reliable.

Eep. And noisy. You should probably compare the output of:

hg debugdata .hg/store/00changelog.i <rev>

..in the two instances. That'll show you the actual data that gets
hashed.

As mentioned before, minor tweaks here over time mean that we won't
exactly reproduce some very old changesets when converting.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial mailing list