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

[Mads Kiilerich]

Peter Hosey wrote, On 06/26/2011 12:26 AM:
> I'm converting a Mercurial repository to Mercurial using a filemap to exclude a couple of files.
>
> Now you might be thinking “well yeah, excluding those files changes the revision that added them and all subsequent revs”, but that's not what I'm talking about.
>
> This revision is way, way, *way* older than the excluded files. No other files are excluded, and there is no splicemap, branchmap, or authormap in place.
...
> I checked the SHA-1 of images/icons/whistle.psd in each repo. It's 52d8343c6b4cebe55e3b9f9b5eae2bd15344b326 in both. diff -s confirms that both files have identical contents.
>
> So, why is the node ID different in the converted repo, and what can I do about this (or is it a bug)?

The changeset id is a hash derived from the file content and all meta 
data of the changeset and all its ancestors. You are right that it 
should be stable over conversion, and usually it is.

There has however over time been some changes to how Mercurial 
represents the data it hashes - mostly fixes for ambiguities in the 
representation, for example the ordering. The repository created by 
convert will use the new (stable) representation instead of the old 
(ambiguous) representation and that might change the hash.

If you want to preserve the hashes up to the point where convert really 
makes some changes then you might be able to do it by first creating a 
clone containing only the stable changesets and then convert the rest of 
the changesets but specify a start rev and a splice map.

/Mads