divergence using the convert extension

[Matt Harbison]

On Thu, 21 Jun 2018 04:52:09 -0400, Benoit Fouletier <bennews at free.fr>  
wrote:

> I have a pretty big Mercurial repo (40 GB), from a Unity game developed
> over almost 3 years, by over a dozen contributors.
> I want to make a new game using the same codebase/engine, but I'd like to
> get rid of (most of) the content to avoid starting with a bloated repo.
> Basically, the game's textures and sound files account for 90% of the  
> repo
> size, so I want to strip that. But obviously, I want to keep the history.

The built in LFS extension might be helpful here.  Converting to LFS would  
allow you to keep the large files out of the repo data, and not change the  
hashes in the conversion process.

> Second thing is, since I didn't modify anything (yet) during the
> conversion, I was expecting the hashes to stay intact (and ideally the  
> end
> result to be bitwise identical), but that's not what I'm seeing.
> I tracked it down, the first 11K changesets have identical hashes, until
> one changeset (a merge actually) suddenly diverges. I exported both the
> original and converted changesets as patches, and diffed the patches: I
> don't see any diff (expect for the hash itself), can't figure out why it
> diverges. I'm wondering if it could be a line ending issue, although no
> diff are readily appearant, and even so why would convert introduce a
> change?
>
> Obviously since I'm gonna strip stuff anyway, I _will_ diverge from the
> original pretty early and will lose all hashes, that's fine, this is more
> out of curiosity and making sure nothing too fishy it going on.

I hit a similar issue last year helping someone recover from repo  
corruption.  (Convert was involved in the recovery somehow.)  On the first  
divergent commit, run `hg log -r $rev --debug` in both repos.  IIRC, the  
manifest line was different.  It was reproducible, but I couldn't figure  
out how to recreate it with a simple test case.