Desired use case for obsmarkers / visibility

Augie Fackler raf at durin42.com
Fri Nov 10 17:58:34 EST 2017


(+junw for visibility in case he's got an idea, +martinvonz in case he
remembers downsides we thought of I've since forgotten.)

On Thu, Nov 02, 2017 at 10:06:43AM -0700, Gregory Szorc wrote:
> I have a potential use case for obsmarkers / visibility that I want to run
> by people to see if it can be supported.

[...]

> Instead of performing backouts and leaving the final repo history in a
> sub-optimal state, we want to instead "drop" "bad" changesets before they
> are published. e.g.
>
> o E' (draft) (rebased from discarded D to C)
> |     x D (draft) (discarded)
> o C (public)
> o B (public)
> o A (public) (root)
>
> Since we can identify "bad" changesets relatively quickly, this would
> enable us to remove the vast majority of backouts and "bad" changesets from
> the final, published repo history.
>
> Again, obsolescence as it exists today facilitates this. We can perform
> these drops via `hg histedit` (or similar) and the appropriate "prune"
> obsmarkers are written so the canonical repo has the appropriate final
> history.
>
> However, the way it works today isn't friendly to end-user workflows.
>
> If we were to deploy this, the following would happen:
>
> 1) User creates changeset X and submits for landing.
> 2) Landing service rebases to X' and writes X->X' marker.
> 3) X' turns out to be bad and is dropped. X'->null marker is written to
> convey the prune.
> 4) User pulls and sees X->X'->null and hides X because its most recent
> successor is pruned.
> 5) User is left wondering what happened to X. They possibly forget they
> need to fix and reland X.
>
> This is bad UX. What we want to happen instead is:
>
> a) User pulls after X' drop and X is still visible.
> b) Something else happens and some form of X remains visible/accessible to
> user
>
> The server can't expose X' because everyone would see it. We have 1 head
> per repo and don't want to be exposing random "bad" changesets to everyone.
> This seems to rule out the traditional evolve solution of "touch" a
> changeset to revive a prune because I'm not sure how we'd send X' to only
> the user that cares about it. There's also no way in obsolescence today to
> unhide X once it has been obsoleted.

[...]

>
> I /think/ the new visibility work proposed by Jun, Durham, and others might
> offer some solutions to this problem. Rather than speculate based on my
> limited knowledge of that proposal, I am hoping someone with more knowledge
> could weigh in more definitively.

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).

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.

Thoughts?


More information about the Mercurial-devel mailing list