[PATCH 4 of 4 V2] obsolete: allow cycles

[Sean Farley]

Jun Wu <quark at fb.com> writes:

> Excerpts from Gregory Szorc's message of 2017-03-21 21:25:03 -0700:
>> Correct me if I'm wrong, but can't incorrect clocks result in the "wrong"
>> version of a changeset being visible? For example, I'm working on different
>> machines and pushing changes to a central server. I create divergence then
>> correct it later via various obsolescence markers. But, because of clocks,
>
> Let's look at an example of divergence:
>
>     o   C (amended from A)
>     |
>     | o B (amended from A)
>     |/
>     x   A
>
> If you see the above divergence in one machine, fix it by "hg prune B -s C",
> and verify the fix on that machine, then the fix could be applied globally.
> That means, if the related markers are sent to elsewhere, the fix will be
> observed elsewhere as expected.
>
> If the clock was wrong, what you may notice is "hg prune" looks like a
> no-op. But it does not unhide things.
>
> In this case only "A" is hidden, since you are not creating markers
> involving "A" to resolve the divergence, nothing gets "unhidden".
>
>
> I'm trying to construct a case that you may be concerned about, to explain
> the difference caused by date:
>
>                                         o C (amended from B)
>                                         |   (marker 2.2)
>     o B (amended from A)                | x B (amended from A)
>     |   (marker 1.1)                    |/    (marker 2.1)
>     x A                                 x A
>
>     Machine 1                          Machine 2
>
> Then if Machine 1 gets markers from Machine 2, if marker 1.1 is newer than
> marker 2.1, B stays visible and is a divergence. You may think "B" should be
> hidden, but that's also explainable. Think about the following order:
>
>     1. hg amend # A -> B
>     2. hg amend # B -> C
>     3. hg update --hidden -r A; ...; hg amend # A -> B
>
> If "3" is the latest operation, it has the intention to make whatever it
> creates visible - that's B. And that creates a divergence.
>
> The key here is the order of operation 2 and 3. If 2 happens after 3, then B
> gets hidden as expected. Currently, this cycle will get both B and C hidden,
> which I don't think is a sane behavior.
>
>> the "wrong" changeset is unhidden and I unknowingly start basing new work
>> on it instead of the "correct" changeset. I accidentally land a predecessor
>> because I assumed obsolescence "just worked" and introduce a subtle bug in
>> the process.
>> 
>> What are the processes in place to prevent this from happening? How will a
>> power user even know to use a power command to fix the situation?
>
> They will notice an hg command looks like a no-op. And we may be able to
> print some friendly help about how to fix it, or just write a faked date
> automatically with a warning.
>
>> >
>> > Not to mention most systems have sane clocks,
>> 
>> This is dangerous to believe.
>> 
>> Anecdotally, I've experienced the following problems on just the machines I
>> use day-to-day:
>> 
>> * An old battery on a motherboard caused the system clock to go haywire,
>> drifing so fast that the default ntp configuration failed to readjust the
>> clock fast enough, leading to clock skew on the order of several minutes.
>> Other times, the system would boot up without any persisted time, thinking
>> it was at some epoch. This resulted in mtimes decades in the past.
>> 
>> * Hyper-V attempts to adjust the system clock inside running Linux VMs by
>> default. Windows was on California time but the Linux VM was on UTC. The
>> timezones conflicts and every few seconds Hyper-V and something in systemd
>> would race to fix the system time. The system time bounced around 7 hours
>> at a time.
>> 
>> * Virtual machines (in Virtualbox IIRC) resumed after hibernate with the
>> system time from when they were powered down. It took several seconds or
>> minutes for NTP or some other process to kick in to adjust the VM's clock
>> to reality.
>> 
>> And these problems all occurred on machines with internet connectivity.
>> Could you imagine what would happen if they weren't able to communicate
>> with an NTP server?
>
> As I said, the worst case is only about visibility - no repo corruption, no
> data loss, no broken consistency (ex. two synchronized repos have different
> understanding about things). And visibility is possible to fix by simply
> adding markers.

Let's take a step back for a minute. Technical discussions aside (and
they are, indeed, very technical), is this a feature that we should be
concentrating on *right now*?

I worry that evolve is already too complicated and we haven't done the
first tasks of bringing bits of it into core. I've overheard from some
Bitbucket co-workers (that prefer to not chime in)[1] that it's getting
a bit out of hand with everyone implementing every single niche feature
they want and no one seems to be around to herd these cats.

If this feature is really, really needed, then fine. My only purpose
here is to ask the current leaders: in all honesty, how will we, as a
community, avoid over-engineering Mercurial into JIRA?


[1] https://www.youtube.com/watch?v=DG0Quq36c5s