[Monotone-devel] [PATCH] mtn-bisect and toposort/log question

[Łukasz Krotowski]

Hi,
I attached patch with first version of mtn-bisect script. It's regression
search tool modeled after git-bisect. It doesn't provide git's automation
and logging for now. And has some not tested fail paths, and some not found
bugs also. Nevertheless it was quite helpful in searching for first revision
with possible bug: <http://savannah.nongnu.org/bugs/?20711>.

Usage is similar to git-bisect. Just mtn-bisect good LAST_GOOD_REVID,
mtn-bisect BAD_REV_ID, mtn-bisect start. And recompile/test/mtn-bisect good
| mtn-bisect bad cycle.

Well, just see if you like it. And commit upstream if it's good enough. Any
suggestions are welcomed.

Also, I've got a question. With both mtn automate toposort and mtn log
(monotone, branch net.venge.monotone) there is such output:

1) 11a06ec25f1d3382189b3d39cc0f9e6c7983186f 2007-06-14T21:28:32
2) 55434f89a7caebea111d02af424d7bdd35b357a1 2007-05-25T17:15:33
3) 2d18283fb2482e98ac5f9d29076804b9d8adbb13 2007-05-24T20:41:22
4) 09655aae0a7b9ab2a30f5a9ed36cc8719838d5a1 2007-06-14T12:22:34
...

Revision (1) is merge of (2) and (4). I know it's topological order but it's
also somehow illogical. ;) Is there possibility to adjust toposort algorithm
to select such a order where merge ancestors are sorted by time cert?

It would make log output more readable. And when it comes to mtn-bisect
order as above causes false positives (revisions 1 and 4 are marked bad and
2, 3 good, which make them local maximum): (1) can be found as first bad
revision.

Cheers,
Lukasz Krotowski

mtn-bisect.patch
Description: Binary data