Desired use case for obsmarkers / visibility

[Boris Feld]

[...]
> 
> > 
> > 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.
Adding a new command line flag would generate confusions for users as
they could forget to use 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.

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

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.

Augie, why did you come up with this proposal? Did you have a specific
workflow or use-case in mind a year ago?

> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel