Tue, 02 Feb 2016 09:46:14 -0800 verify: drop unnecessary check for nullid
Martin von Zweigbergk <martinvonz@google.com> [Tue, 02 Feb 2016 09:46:14 -0800] rev 28112
verify: drop unnecessary check for nullid In eb914541a950 (verify: filter messages about missing null manifests (issue2900), 2011-07-13), we started ignoring nullid in the list of manifest nodeids to check. Then, in b32a30da608d (verify: do not choke on valid changelog without manifest, 2012-08-21), we stopped adding nullid to the list to start with. So let's drop the left-over check now.
Sun, 31 Jan 2016 00:10:56 -0800 verify: move cross-checking of changeset/manifest out of _crosscheckfiles()
Martin von Zweigbergk <martinvonz@google.com> [Sun, 31 Jan 2016 00:10:56 -0800] rev 28111
verify: move cross-checking of changeset/manifest out of _crosscheckfiles() Reasons: * _crosscheckfiles(), as the name suggests, is about checking that the set of files files mentioned in changesets match the set of files mentioned in the manifests. * The "checking" in _crosscheckfiles() looked rather strange, as it just emitted an error for *every* entry in mflinkrevs. The reason was that these were the entries remaining after the call to _verifymanifest(). Moving all the processing of mflinkrevs into _verifymanifest() makes it much clearer that it's the remaining entries that are a problem. Functional change: progress is no longer reported for "crosschecking" of missing manifest entries. Since the crosschecking phase takes a tiny fraction of the verification, I don't think this is a problem. Also, any reports of "changeset refers to unknown manifest" will now come before "crosschecking files in changesets and manifests".
Sun, 31 Jan 2016 21:55:52 -0800 tests: add tests for missing revlogs and revlog entries
Martin von Zweigbergk <martinvonz@google.com> [Sun, 31 Jan 2016 21:55:52 -0800] rev 28110
tests: add tests for missing revlogs and revlog entries The verify code is pretty poorly tested. It's easy to test missing revlogs and missing revlog entries, so let's add tests for that. Also add some more tests corrupting each type of revlog, so we test the messages presented when reading a revision fails. The pure and native implementations produce different error messages, so we have to use (glob) in the tests.
Fri, 12 Feb 2016 14:50:10 -0800 hook: don't crash on syntax errors in python hooks
Siddharth Agarwal <sid0@fb.com> [Fri, 12 Feb 2016 14:50:10 -0800] rev 28109
hook: don't crash on syntax errors in python hooks We had some real-world cases where syntax errors in Python hooks would crash the whole process and leave it in an indeterminate state. Handle those better.
Fri, 12 Feb 2016 11:44:35 -0800 hook: for python hook exceptions, add note to run with --traceback
Siddharth Agarwal <sid0@fb.com> [Fri, 12 Feb 2016 11:44:35 -0800] rev 28108
hook: for python hook exceptions, add note to run with --traceback Just like with ImportErrors, it isn't obvious that --traceback will produce helpful debugging output here.
Fri, 12 Feb 2016 11:42:18 -0800 hook: add tests for failing post- python hooks
Siddharth Agarwal <sid0@fb.com> [Fri, 12 Feb 2016 11:42:18 -0800] rev 28107
hook: add tests for failing post- python hooks I couldn't find any tests for this.
Fri, 12 Feb 2016 11:34:04 -0800 hook: even fewer parentheses for load errors
Siddharth Agarwal <sid0@fb.com> [Fri, 12 Feb 2016 11:34:04 -0800] rev 28106
hook: even fewer parentheses for load errors Missed this one.
Mon, 08 Feb 2016 17:34:32 +0100 destutil: document various failure cases
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 08 Feb 2016 17:34:32 +0100] rev 28105
destutil: document various failure cases We document what various conditional branch mean and clarify that they are exclusive (since they all end up in with exception raised).
Mon, 08 Feb 2016 14:56:28 +0100 destutil: consistently retrieve 'p1' and 'branch'
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 08 Feb 2016 14:56:28 +0100] rev 28104
destutil: consistently retrieve 'p1' and 'branch' We already read p1 from the dirstate so let's read the branch from it too.
Mon, 08 Feb 2016 14:55:58 +0100 merge: give priority to "not at head" failures for bare 'hg merge'
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 08 Feb 2016 14:55:58 +0100] rev 28103
merge: give priority to "not at head" failures for bare 'hg merge' We refuse to pick a destination for a bare 'hg merge' if the working copy is not at head. This is meant to prevent strange merge from user who forget to update. (Moreover, such merge does not reduce actually the number of heads) However, we were doing that as the last possible failure type. So user were recommended to merge with an explicit head (from this bad location) if the branch had too many heads. We now make "not on branch heads" class of failure the first things to check and fail on. The one test that change was actually trying to check for these failure (and did not). The new test output is correct.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip