[PATCH 2 of 2] scmutil: add a cleanupnodes method for developers

Jun Wu quark at fb.com
Wed Jun 28 14:08:41 EDT 2017

Excerpts from Martin von Zweigbergk's message of 2017-06-28 10:18:22 -0700:
> I wonder if we should pass in the transaction instead to force the
> caller to think about the transaction scope, even if they all just
> start a new transaction for the cleanup.

Good find. Durham also suggested to remove "operation". I have planned to
add the "desc" information to transaction and use that as operation here.
This function will then require an active transaction, which looks good.

> If we're pruning a merge, this puts the bookmark on an "arbitrary"
> parent. I see that that's how it already works and I suppose you just
> preserved that behavior. Should we simply do the same for the
> divergence case above?  The ProgrammingError is a little unfortunate,
> because the only way to prevent it is by not calling this method, AFAICT
> (sure, you can handle that specific bookmark outside, but then you're not
> saving that much). So maybe just use max() for the divergence too?

The current ProgrammingError only happens when split a commit to something
with multiple roots. Like split A to B and C, and ancestor(B+C) is not in
[B, C]. I think that's a wrong split implementation and therefore raised
ProgrammingError.  Normally you won't be able to get into that situation.

If we don't care about that corner case, I think "max()" makes sense to
simplify the code and user experience.

> Nit: We could probably make that code a bit clearer so the comment
> above about "if s or not isobs(n)" is not needed. Maybe something like
> this:
>             rels = []
>             for node, successors in sorted(mapping.items(), key=sortfunc):
>                 ctx = unfi[node]
>                 if not successors and ctx.obsolete():
>                     continue # already done
>                 rels.append((ctx, (unfi[s] for s in successors)))

Sure. I was just wanting to make the corner case clear: amend A to B, then
prune A. The latter does provide some extra information - intention to
remove A and is in theory a "divergent" from the intention to "amend" A.
That "divergent" is causing unwanted trouble for users since a user will
almost always choose to keep B instead of remove both.

I'll clean up the code and put the explanation in commit message.

> Same comment as on another patch: we're on Python 2.7, so can combine
> these with-blocks.

I actually didn't know that syntax until yesterday :)

More information about the Mercurial-devel mailing list