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

[Haszlakiewicz, Eric]

> -----Original Message-----
> From: mercurial-bounces at selenic.com [mailto:mercurial-
> bounces at selenic.com] On Behalf Of Peter Hosey
> 
> 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.
> 
> 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.

I've run into this problem several times before.  If your repository was originally created with old versions of mercurial then some of the metadata can end up in a different order.  In my case, it happen to be that the "copyrev" info for files that had been moved ended up at a different line in mercurial's internal data format.

Tracking down the exact difference is a bit more difficult than just what Matt said:

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

You actually need to start with that, then use the first line of that output to grab the individual file entries from the manifest:

> hg debugdata .hg/store/00manifest.i <rev-from-changelog.i>

That lists *all* files in the repository at that point.  Some of those line will have different id's in the original repository vs. the converted repository.  For each of those, you can then run

> hg debugdata .hg/store/data/path/to/the/file <rev-from-manifest>

which then you can compare the output from that to see what changed.

However, if you just want to get things "working", and aren't so curious as to dig into the exact reason for the difference, I suggest doing a "noop" convert first, just to get the metadata sorted and the changeset id's fixed.  That will require the pain of getting everyone that's cloned that repository to re-clone it, but once you do that you can do your convert with the filemap and know that only the actually different changesets will have different changeset ids.

eric