Desired use case for obsmarkers / visibility

[Jun Wu]

Excerpts from Augie Fackler's message of 2017-11-10 17:58:34 -0500:
> Here's a proposal I ran by Martin probably a year ago, and that he
> didn't immediately hate:
> 
> Prunes are different from regular obsolete markers. By default, you
> don't push prunes, and pulled prunes are not applied, but merely
> warned about. Push and pull could both grow a new flag
> (`--exchange-death` is my intentionally-bad name because I haven't
> come up with a good one).

I think this is reasonable.

Practically, instead of having a separate layer of visibility (which could
take some time to build right). We could implement it as an option of the
exchange protocol so the problematic marker does not get sent to the client
at all. Implementation-wise, this is to stop following the "parent" field
when calculating the obsmarker chain. It sounds easier to implement.
 
> Anecdotally, nearly all of the prune markers in my repo of hg are
> mine, and probably haven't ever been exchanged. In the entire history
> of hg, we've exchanged 21062 prune markers, but only 361 prune markers
> (minus any that are mine, I'm too lazy to make ane extra clone to get
> that info), out of that 21k are actually prunes of something I've got
> locally. I don't know how many of those locally-pruned revisions then
> later got resurrected and finally landed in the repo. That suggests to
> me that we could actually do pretty well by only exchanging prunes
> when it's actually relevant to the destination.

Not directly related to this thread. I'd like note that the above situation
is hg-committed workflow specific. There are users at fb who have tons of
markers which are all their own that even `unfi.revs('draft')` is not
considered cheap.  Shall we start planning for a new visibility layer, I'd
like to see it reduces time complexity calculating phases by filtering out
invisible roots (ex. it is at a lower layer than phases).

> Thoughts?