identical change, different changesetid

[Benoit Boissinot]

On Thu, May 5, 2011 at 8:47 PM, Haszlakiewicz, Eric
<EHASZLA at transunion.com> wrote:
>> -----Original Message-----
>> From: mercurial-bounces at selenic.com [mailto:mercurial-
>>
>> > From: mercurial-bounces at selenic.com [mailto:mercurial-
>> bounces at selenic.com] On Behalf Of Haszlakiewicz, Eric
>> >
>> > I have two repositories that appear to have the exact same changes,
>> to
>> > the exact same files, at the exact same time, but the changeset id
>> for
>> > the most recent changeset is different.  I'm trying to figure out why
>> > this is so.
>> >
>> > I've examined the output of "hg log --debug" and everything I can see
>> is
>> > the same.  The output of hg manifest is identical too.
>> >
>> > If I create two bundles of the differing changeset from each
>> repository,
>> > the bundles are different.  I figured out how to manually uncompress
>> the
>> > bundles (using dd if=bundle bs=4 skip=1 | bzip2 -c -d), and I can see
>> > some obvious differences, but I don't know how to make sense of them.
>> >
>> > How do I figure out why things are different?
>>
>> Is the parent for both changesets exactly the same, too? I mean the
>> hash, not the revision number.
>
> Yep, the first 5 changesets in the "new" repo are exactly the same, including the changeset ids.
> The changes to the files in the 6th changeset look like they're the same (a rename of several files) but the ids are different.
>
>> As for the bundle I can't say too much, maybe the timestamp is somehow
>> used as meta-data and therefore causes a binary diff?
>
> The "new" repo was created with hg convert so I would expect that the timestamp should stay exactly the same.
>
> I thought I heard something a while ago about covert possibly causing different changeset ids due to different order of files in the changeset, and that newer versions of mercurial sort the filenames to ensure consistent changeset ids, but as far as I can tell the order of those is the same.

Renames used to create filelog metadata in an undefined order. Now the
order is deterministic but often different than in the original repo.

cheers,

Benoit