fix out-of-order 'revno' assignment for commits with same timestamp
In src, revision numbers are intended to be simple, consecutive
integers in commit date order. When multiple commits share the same
date, src breaks the tie by using the native commit ID.
Unfortunately, this tie-breaking is based upon lexicographical
comparison, thus can give incorrect results. For instance, with native
ID's (1.1
, 1.2
, ..., 1.10
, 1.11
), lexicographical ordering sorts them
as (1.1
, 1.10
, 1.11
, 1.2
, ...), with 'revno' assignment giving
(__r1__=1.1
, __r2__=1.10
, __r3__=1.11
, __r4__=1.2
, ...). RevisionMixin.pred()
and succ()
work by walking native revision ID's, so topology is unaffected, but
revno
presentation and specification is, adversely so. For instance:
% src list sample.txt
= sample.txt ==========
3 * <date> eleventh
2 - <date> tenth
11 - <date> ninth
10 - <date> eighth
9 - <date> seventh
8 - <date> sixth
7 - <date> fifth
6 - <date> fourth
5 - <date> third
4 - <date> second
1 - <date> first
This sort of situation can arise easily when src fast-import
imports a
history from Git which has undergone interactive rebasing, which can set
the committer timestamp of many commits to the same value. For example,
given git rebase -i HEAD~50
, after commit HEAD~50
is edited, the
committer timestamp of the remaining 49 commits will likely have the
same value when replayed atop HEAD~50
.
Fix by sorting native ID's with natural ordering rather than lexicographical.