The line content of continued Subject: lines was yet joined via
str.replace('\n\t', ' '), which does not handle continuation via
spaces. So expan the regular expression instead to
handle all allowed forms of mail header line continuation.
It is apparently possible to compile Python without SSL support or leave it out
when installing precompiled binaries.
Mercurial on such Pythons would crash if the user tried to use https. Now it
will be reported as "abort: Python SSL support not found" instead.
Before, the right-hand side of a .hgsub entry was used, as is, to
match the left-hand side of a subpaths entry. This turned out to be
less useful than expected since a .hgsub file with
src/foo = src/foo
has little context to do remapping on. The new idea is therefore to
prefix the parent repo path *before* the remapping takes place.
If the parent repository path (as defined by _abssource) is
http://example.net/parent
then the remapping for the above .hgsub entry will be done on the
expanded path:
http://example.net/parent/src/foo
If this expanded path is not changed by the remapping, then we remap
src/foo
alone. This is the old behavior where the right-hand side is remapped
without context.
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>
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>
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>
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>
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.
The 'ignored' changesets are outside the bisection range, but are
changesets that may have an impact on the outcome of the bisection.
For example, in case there's a merge between the good and bad csets,
but the branch-point is out of the bisection range, and the issue
originates from this branch, the branch will not be visited by bisect
and bisect will find that the culprit cset is the merge.
So, the 'ignored' set is equivalent to:
( ( ::bisect(bad) - ::bisect(good) )
| ( ::bisect(good) - ::bisect(bad) ) )
- bisect(range)
- all ancestors of bad csets that are not ancestors of good csets, or
- all ancestors of good csets that are not ancestors of bad csets
- but that are not in the bisection range.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Use repo.set() wherever possible, instead of locally trying to
reproduce complex graph computations.
'pruned' now means 'all csets that will no longer be visited by the
bisection'. The change is done is this very patch instead of its own
dedicated one becasue the code changes all over the place, and the
previous 'pruned' code was totally rewritten by the cleanup, so it
was easier to just change the behavior at the same time.
The previous series went in too fast for this cleanup pass to be
included, so here it is. ;-)
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
If Python interpreter was built under Linux 3.x kernel, it reports
sys.platform to be 'linux3' (it is fixed for Python 3, but not for 2.x).
This cancels building inotify extension, which was built only for 'linux2'
platform. Improved test checks if sys.platform begins with 'linux', and together
with test for kernel version to be greater than 2.6 it seems to cover all known
cases.
The 'untested' set is made of changesets that are in the bisection range
but for which the status is still unknown, and that can later be used to
further decide on the bisection outcome.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The 'pruned' set is made of changesets that did participate to
the bisection. They are made of
- all good changesets
- all bad changsets
- all skipped changesets, provided they are in the bisection range
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The 'range' set is made of all changesets that make the bisection
range, that is
- csets that are ancestors of bad csets and descendants of good csets
or
- csets that are ancestors of good csets and descendants of bad csets
That is, roughly equivalent of:
bisect(good)::bisect(bad) | bisect(bad)::bisect(good)
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Computing the ranges of csets in the bisection belongs to the hbisect
code. This allows for reusing the status computation from many places,
not only the revset code, but also to later display the bisection status
of a cset...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Rename the 'bisected' keyword to simply 'bisect'.
Still accept the old name, but no longer advertise it.
As discussed with Matt on IRC.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
We only deny rebasing onto direct parent. Thanks to the ancestor argument of
merge. the "implementation" of this feature only consist in loosing the check
and imply detach when rebasing on ancestor.
If the working dir parent was destroyed by rollback, then the old
behaviour is perfectly reasonable: restore dirstate, branch, and
bookmarks. That way the working dir moves back to an existing
changeset rather than becoming an orphan.
But if the working dir parent was unaffected -- say, you updated to an
older changeset and then did rollback -- then it's silly to restore
dirstate and branch. So don't do that. Leave the status of the working
dir alone. (But always restore bookmarks, because that file refers to
changeset IDs that may have been destroyed.)
- clarify how we parse undo.desc
- fix bad grammar in an error message
- factor out ui local
- rename some local variables
- standardize string quoting
Formerly RST blocks were formatted without a trailing newline, which
wasn't particularly helpful. Now everything that comes back from the
formatter has a trailing newline so remove all the extra ones added by
users.
- move the obscure parts into the verbose help
- drop confusing references to "remove from repository" / "not remove
from history"
- add mention of hg forget
