<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Nov 15, 2017 at 8:23 AM, Augie Fackler <span dir="ltr"><<a href="mailto:raf@durin42.com" target="_blank">raf@durin42.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
> On Nov 14, 2017, at 14:48, Boris Feld <<a href="mailto:boris.feld@octobus.net">boris.feld@octobus.net</a>> wrote:<br>
><br>
> [...]<br>
>><br>
>>><br>
>>> I /think/ the new visibility work proposed by Jun, Durham, and<br>
>>> others might<br>
>>> offer some solutions to this problem. Rather than speculate based<br>
>>> on my<br>
>>> limited knowledge of that proposal, I am hoping someone with more<br>
>>> knowledge<br>
>>> could weigh in more definitively.<br>
>><br>
>> Here's a proposal I ran by Martin probably a year ago, and that he<br>
>> didn't immediately hate:<br>
>><br>
>> Prunes are different from regular obsolete markers. By default, you<br>
>> don't push prunes, and pulled prunes are not applied, but merely<br>
>> warned about. Push and pull could both grow a new flag<br>
>> (`--exchange-death` is my intentionally-bad name because I haven't<br>
>> come up with a good one).<br>
>><br>
>> Anecdotally, nearly all of the prune markers in my repo of hg are<br>
>> mine, and probably haven't ever been exchanged. In the entire history<br>
>> of hg, we've exchanged 21062 prune markers, but only 361 prune<br>
>> markers<br>
>> (minus any that are mine, I'm too lazy to make ane extra clone to get<br>
>> that info), out of that 21k are actually prunes of something I've got<br>
>> locally. I don't know how many of those locally-pruned revisions then<br>
>> later got resurrected and finally landed in the repo. That suggests<br>
>> to<br>
>> me that we could actually do pretty well by only exchanging prunes<br>
>> when it's actually relevant to the destination.<br>
>><br>
>> Thoughts?<br>
><br>
> Exchanging prune obsmarkers is already part of distributed workflows.<br>
<br>
</div></div>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.)<br>
<span class=""><br>
> Adding a new command line flag would generate confusions for users as<br>
> they could forget to use it.<br>
<br>
</span>I envision it'd be something like this:<br>
<br>
  $ hg push -r foo someserver<br>
  [discovery, exchange, etc output]<br>
  warning: someserver has draft changes which are pruned locally: [somehashes]<br>
  (push those changes with --exchange-death to remove them from the server)<br>
<br>
And a similar thing on pull:<br>
<br>
  $ hg pull someserver<br>
  [discovery, exchange, etc output]<br>
  warning: someserver has pruned changes which are drafts locally: [somehashes]<br>
  (accept the pruning by pulling again with --exchange-death)<br>
<br>
(obviously --exchange-death is a bad flag name. Please don't dwell on it.)<br>
<span class=""><br>
> At the moment, if user A prunes a changeset X and pushes, then user B<br>
> pulls with this changeset X available locally, they both would have the<br>
> changeset X hidden.<br>
><br>
> With this proposal, if user A forgets to add the flag when pushing or<br>
> if user B forgets to add it when pulling, changeset X will still be<br>
> visible in user B repository.<br>
><br>
> Hiding pruned changeset on pull is currently used by people and<br>
> companies that find it useful.<br>
<br>
</span>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.<br>
<span class=""><br>
><br>
> To illustrate, at Octobus, we are using a distributed evolution<br>
> workflow on both Evolve and Mercurial. On our development repositories,<br>
> about 10% of prune markers points to changesets known by our server.<br>
> And that ratio would increase if we stopped using prune markers for the<br>
> purposes of cleaning up internal nodes (eg: histedit).<br>
<br>
</span>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?<br>
<br>
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.<br>
<span class=""><br>
> Besides this proposal, I think that another solution based either on<br>
> secrets changesets or non-owner prune markers could be a better<br>
> solution to Gregory's problem, see the discussion in the thread branch.<br>
<br>
</span>I'm dubious, because I do work on hg as both <a href="mailto:augie@google.com">augie@google.com</a> and <a href="mailto:raf@durin42.com">raf@durin42.com</a>. Which means that I might have a "non-owner" prune marker.<br>
<br>
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.<br>
<span class=""><br>
> Augie, why did you come up with this proposal? Did you have a specific<br>
> workflow or use-case in mind a year ago?<br>
<br>
</span>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.<br>
<br>
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.<br>
<br>
<br>
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.<br></blockquote><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div></div></div></div>