[Monotone-devel] code review in practice

[Evan Martin]

Does anyone have experience using monotone for code review?
What process do you use?  The manual mentions that some Lua hooks
could be used for code review
(http://monotone.ca/docs/Quality-Assurance.html#Quality-Assurance) but
doesn't go into much detail.

Three possibilities I can see:
1) Submitters send patches to a mailing list and don't commit until
it's been verbally ok'd.
Analysis: doesn't really use monotone any different than e.g. CVS.

2) Submitters make a (named) branch for each new change, branch only
merged into the main branch after it's been ok'd.
Analysis: a new branch name for every change seems a little scary.

3) Submitters commit anonymous branches, reviewers add a cert.
Analysis: this is what I imagine was intended.  But the two options seem to be
a) certifying the edges, which requires approving each edge in the branch (?)
b) certifying the endpoints of an update, which the docs indicate
maybe are for testing?

Maybe it'd be best if I dumped an example and you can correct me.  :)
Imagine you have a revision graph like:

1
| \
| 2
3 |
| 4
| /
5

Where 1 is a known-good branch, 2 is someone's first change, 3 is
another mainline approved change, 4 is their updated change after
feedback, and 5 is the eventual commit of that change.  (Imagine the
numbers increase with time as well.)

As a reviewer I think I want to approve the 4-5 edge, but I'm unclear
if that means I need to approve 2-4 as well.  If someone else came
along during this process and just checked out the "head" branch, I'd
want them to get (depending on when they came along) 1, 3, or 5, but
never 2 or 4 unless they explicitly requested it and not 5 until the
4-5 edge has been approved.

Command lines and Lua samples welcomed.