Transferring changeset approval status to rebased successors

Manuel Jacob me at manueljacob.de
Sat Mar 25 21:10:26 UTC 2023


Hi,

In one project I’m working on, we do code review of single changesets in 
a feature branch (usually the changesets are quite small and on average 
more than 10 are submitted for review at the same time). We also use 
Mercurial’s changeset evolution quite heavily. Feature branches are 
rebased regularly and single changesets are amended between two reviews 
(causing the descendants of these changesets to be rebased by the evolve 
extension).

Currently, we track the review status of each of these changesets 
manually. After the branch is rebased, each of the rebased changesets is 
shown as unreviewed in Kallihea. It would be a significant improvement 
if Kallithea showed for each changeset whether an “unchanged” 
predecessor was already approved.

Thanks to the obsoleteness markers provided by Mercurial, this is easy 
to determine. The algorithm would walk through the predecessors if there 
is only one and only the parent changed in between them, until it hits a 
changeset whose status is not “unreviewed”.

One question is how to show this information to the user. What would 
work for me is to show "approved predecessor" in all places where 
"approved" can be shown. Instead of a green circle, it could show the 
outline of a green circle. (The same could be applied to “under review” 
and “not approved”).

Another question is when to run the logic. Running it each time the 
review status is shown somewhere would work good enough for us. Caching 
this is not easy. It would need to be invalidated each time a 
predecessor is added or its review status is changed. Recomputing it 
each time shouldn’t be a problem in practice because the obsoleteness 
markers are stored in-memory, the number of considered predecessors is 
limited (until the algorithm hits a “changed” or already reviewed 
predecessor) and in most places where the review status is shown, the 
changeset description is also shown, which has to be read from disk, so 
walking the predecessors should not contribute much to the total time.

What do you think?


More information about the kallithea-general mailing list