util: fix crash converting an invalid future date to string
Post-2038 timestamps cannot be handled on 32-bit architectures. Clamp
such dates to the maximum 32-bit timestamp.
styles: add new 'bisect' style that prints the bisection status
The style is based on the 'default' style, but adds the bisection status
of the changesets.
Example output for a changeset in range:
$ hg log --style bisect -r 15:16
changeset: 15:
857b178a7cf3
bisect: bad
parent: 13:
b0a32c86eb31
parent: 10:
429fcd26f52d
user: test
date: Thu Jan 01 00:00:15 1970 +0000
summary: merge 10,13
changeset: 16:
609d82a7ebae
bisect: bad (implicit)
user: test
date: Thu Jan 01 00:00:16 1970 +0000
summary: 16
$ hg log --quiet --style bisect
18:
d42e18c7bc9b
B 17:
228c06deef46
B 16:
609d82a7ebae
B 15:
857b178a7cf3
14:
faa450606157
G 13:
b0a32c86eb31
G 12:
9f259202bbe7
G 11:
82ca6f06eccd
U 10:
429fcd26f52d
S 9:
3c77083deb4a
G 8:
dab8161ac8fc
7:
50c76098bbf2
I 6:
a214d5d3811a
I 5:
385a529b6670
I 4:
5c668c22234f
I 3:
0950834f0a9c
I 2:
051e12f87bf1
1:
4ca5088da217
0:
33b1f9bc8bc5
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
templates: add 'bisect' keyword to return a cset's bisect status
This new 'bisect' template expands to a cset's bisection status (good,
bad and so on...). There is also a new 'shortbisect' filter that yields
a single char representing the cset's bisection status.
It uses the two recently-added hbisect.label() and .shortlabel() functions.
Example output using the repository in test-bisect2.t, and some made-up
state of the 'end at merge' test (with graphlog, it's so explicit):
$ hg glog --template '{rev}:{node|short} {bisect}\n' \
-r 'bisect(range)|bisect(ignored)'
o 17:
228c06deef46: bad
|
o 16:
609d82a7ebae: bad (implicit)
|
o 15:
857b178a7cf3: bad
|\
| o 13:
b0a32c86eb31: good
| |
| o 12:
9f259202bbe7: good (implicit)
| |
| o 11:
82ca6f06eccd: good
| |
@ | 10:
429fcd26f52d: untested
|\ \
| o | 9:
3c77083deb4a: skipped
| |/
| o 8:
dab8161ac8fc: good
| |
o | 6:
a214d5d3811a: ignored
|\ \
| o | 5:
385a529b6670: ignored
| | |
o | | 4:
5c668c22234f: ignored
| | |
o | | 3:
0950834f0a9c: ignored
|/ /
o / 2:
051e12f87bf1: ignored
|/
And now the same with the short label:
$ hg log --template '{bisect|shortbisect} {rev}:{node|short}\n'
18:
d42e18c7bc9b
B 17:
228c06deef46
B 16:
609d82a7ebae
B 15:
857b178a7cf3
14:
faa450606157
G 13:
b0a32c86eb31
G 12:
9f259202bbe7
G 11:
82ca6f06eccd
U 10:
429fcd26f52d
S 9:
3c77083deb4a
G 8:
dab8161ac8fc
7:
50c76098bbf2
I 6:
a214d5d3811a
I 5:
385a529b6670
I 4:
5c668c22234f
I 3:
0950834f0a9c
I 2:
051e12f87bf1
1:
4ca5088da217
0:
33b1f9bc8bc5
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
hbisect: add functions to return a label for a cset bisection status
Add two new functions that return a string containing the bisection status
of the node passed in parameter:
- .label(node): return a multi-char string representing the status of node
- .shortlabel(node): return a single-char string representing the status
of node, usually the initial of the label
bisection status .label() .shortlabel()
----------------------------------------------------------
good 'good' 'G'
good (implicit) 'good (implicit)' 'G'
bad 'bad' 'B'
bad (implicit) 'bad (implicit)' 'B'
skipped 'skip' 'S'
untested 'untested' 'U'
ignored 'ignored' 'I'
(others) None None
There is no point in returning 'range' or 'pruned', as these get covered
by another, more meaningful status in the table above.
In case the node is not being bisected, the functions return None to leave
it up to the caller to decide what to print (nothing, an empty space, or
whatever else suits).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
hbisect: add two new revset descriptions: 'goods' and 'bads'
This patch adds two new revset descriptions:
- 'goods': the list of topologicaly-good csets:
- if good csets are topologically before bad csets, yields '::good'
- else, yields 'good::'
- and conversely for 'bads'
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
http: handle push of bundles > 2 GB again (
issue3017)
It was very elegant that httpsendfile implemented __len__ like a string. It was
however also dangerous because that protocol can't handle sizes bigger than 2 GB.
Mercurial tried to work around that, but it turned out to be too easy to
introduce new errors in this area.
With this change __len__ is no longer implemented at all and the code will work
the same way for short and long posts.