Desired use case for obsmarkers / visibility

Gregory Szorc gregory.szorc at
Wed Nov 15 12:08:14 EST 2017

On Wed, Nov 15, 2017 at 8:23 AM, Augie Fackler <raf at> wrote:

> > On Nov 14, 2017, at 14:48, Boris Feld <boris.feld at> wrote:
> >
> > [...]
> >>
> >>>
> >>> 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?
> >
> > Exchanging prune obsmarkers is already part of distributed workflows.
> Irrelevant: obsolete markers are marked experimental, and evolve isn't in
> core (for precisely this kind of reason! We're still figuring out the right
> behaviors at the margin.)
> > Adding a new command line flag would generate confusions for users as
> > they could forget to use it.
> I envision it'd be something like this:
>   $ hg push -r foo someserver
>   [discovery, exchange, etc output]
>   warning: someserver has draft changes which are pruned locally:
> [somehashes]
>   (push those changes with --exchange-death to remove them from the server)
> And a similar thing on pull:
>   $ hg pull someserver
>   [discovery, exchange, etc output]
>   warning: someserver has pruned changes which are drafts locally:
> [somehashes]
>   (accept the pruning by pulling again with --exchange-death)
> (obviously --exchange-death is a bad flag name. Please don't dwell on it.)
> > At the moment, if user A prunes a changeset X and pushes, then user B
> > pulls with this changeset X available locally, they both would have the
> > changeset X hidden.
> >
> > With this proposal, if user A forgets to add the flag when pushing or
> > if user B forgets to add it when pulling, changeset X will still be
> > visible in user B repository.
> >
> > Hiding pruned changeset on pull is currently used by people and
> > companies that find it useful.
> I don't disagree, but it's *extremely* rare experimentally on hg. I'd
> encourage running a similar analysis on your own repositories to get a
> sense of how many prunes have ever been meaningfully exchanged. I bet it's
> a fraction of a percent of markers, and happens extremely rarely overall.
> >
> > To illustrate, at Octobus, we are using a distributed evolution
> > workflow on both Evolve and Mercurial. On our development repositories,
> > about 10% of prune markers points to changesets known by our server.
> > And that ratio would increase if we stopped using prune markers for the
> > purposes of cleaning up internal nodes (eg: histedit).
> Sure, but what's the actual number of pruned revisions? how many
> discontinuous revision ranges does that represent? How many of those pruned
> revisions were pruned after they'd been widely distributed?
> I know there's a lot of conceptual purity in having all markers be global
> state, and always be exchanged. I just think it's misguided conceptual
> purity that results in a more confusing user experience in the case of
> something getting accepted and then dropped, or in the case of a tryserver
> that wants to inject prunes as a matter of course for cleaning things up.
> > Besides this proposal, I think that another solution based either on
> > secrets changesets or non-owner prune markers could be a better
> > solution to Gregory's problem, see the discussion in the thread branch.
> I'm dubious, because I do work on hg as both augie at and
> raf at Which means that I might have a "non-owner" prune marker.
> Besides, if I've adopted a change of smf's, and it ends up pruned (see
> below for a hypothetical), it's not even *my* change that I'm going to have
> to go search for to resurrect.
> > Augie, why did you come up with this proposal? Did you have a specific
> > workflow or use-case in mind a year ago?
> It's pretty much exactly indygreg's case. Let's say Alice reviews a
> change, and pushes it to hg-committed. Bob discovers a problem with it, and
> marks it as pruned.
> Charlie contributor now has a problem: his copy of the change disappears
> on pull! Right now, on hg, what we do is Bob responds via email to Charlie
> and provides instruction to either manually run `hg touch --hidden
> $PRUNED_SET` or to pull from some other server where Bob has already done
> that for Charlie. Either way, it's an extra manual step Charlie shouldn't
> have to worry about at all in order to not lose his work.
> That's a concrete problem we have today, but it exposes a larger (IMO)
> problem: 'hg pull' in the presence of prunes has the potential to make work
> *disappear* with no obvious way to get it back. In the case where a change
> is superseded by something else, that scares me less, but in the case of
> "this was bad, discard it and come back to it later" it's extremely non
> obvious to users how to use `hg log --hidden` and `hg touch` to resurrect
> something, and I think making "just remove the revision" acceptance
> explicit and opt-in feels more newbie-friendly, without incurring major
> overhead for pro users.

A similar scenario: multiple people are collaborating with the same repo,
each pushing their draft heads to a central repo. A new developer comes
along and doesn't realize what they are doing. They `hg prune` everyone
else's work because "I didn't want to see it." They `hg push`. On `hg
pull`, everyone else is left scratching their heads about what happened to
their work. Furthermore - and please correct me if I am wrong - there is no
easy way to undo this event without running commands on the server.

One of the golden rules of version control tools is "don't lose the user's
data." I think it can be argued that the current design of prune markers
does violate this rule in a number of scenarios.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Mercurial-devel mailing list