history-reordering extension merits

[Peter Arrenbrecht]

On Thu, Jan 22, 2009 at 3:47 PM, Bill Barry <after.fallout at gmail.com> wrote:
>
> Sorta thinking about all these branch closing threads;
> would it make sense to create some sort of history-reorder extension
> (not rebase, it would merely change local ids so that changesets within
> the same branch are as close as possible together in the graph)? If you
> have the following graph for example:
>
> 5
> |\
> |4
> | |
> 3|
> | |
> | 2
> |/
> 1
>
>
> it would reorder it to be:
>
> 5
> |\
> 4 |
> | |
> | 3
> | |
> | 2
> |/
> 1
> (changeset 3 would now be changeset 4 but would have the same nodeid as
> it did before)
> Effectively changesets 3 and 4 would swap local revision numbers (as if
> you pulled them in a different order).
>
> Is there any purpose for doing this other than to make the graph look a
> little nicer (ie could it make the manifest smaller in a very branchy
> repo or anything like that)?

Yes, it can shrink the manifest if there is a lot of to and fro
between commits to branches with wildly differing manifests. The
hg->hg converter already does something like this, but:

parren: pmezard_: Can hg->hg conversions do topological ordering?
Might answer Bill Barry's question on the list.
pmezard_: convert already does what barry describes by default
pmezard_: there is a --datesort option to preserve date order
pmezard_: but it does not preserve the hashes
parren: Even if I don't rewrite a thing it does not preserve hashes? How so?
pmezard_: parren: i don't remember, perhaps it works, but i remember
brendan and asak having many problems with this
pmezard_: parren: i expect changelog entries to be normalized more or
less differently if they were generated by an old version of mercurial
pmezard_: this kind of stuff

-parren