<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 21, 2017 at 8:44 PM, Jun Wu <span dir="ltr"><<a href="mailto:quark@fb.com" target="_blank">quark@fb.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Excerpts from Gregory Szorc's message of 2017-03-21 19:32:06 -0700:<br>
<div><div class="gmail-h5">> On Tue, Mar 21, 2017 at 3:15 PM, Jun Wu <<a href="mailto:quark@fb.com">quark@fb.com</a>> wrote:<br>
><br>
> > Excerpts from Augie Fackler's message of 2017-03-21 18:03:33 -0400:<br>
> > > > As long as exchange sends dates, markers are globally ordered, and they<br>
> > > > behave no different then the local case.<br>
> > > ><br>
> > > > Say Alice has A -> B created on date1, Bob has B -> A with date2. If<br>
> > date2 ><br>
> > > > date1, Bob wins. The time of pulling or the pull direction does not<br>
> > matter.<br>
> > > > Only the global version (date) matters. If date2 == date1, two markers<br>
> > > > "cancel out" and both A and B become visible.  Previously no matter<br>
> > what the<br>
> > > > dates are, A and B are both permanently invisible.<br>
> > ><br>
> > > I do worry a little about someone with a bogus clock years in the<br>
> > > future pumping out malicious nodes that can't be overridden, but I<br>
> > > suppose in that case your "way out" is that you perturb the hash of<br>
> > > the revision(s) you want to keep. Seem good enough?<br>
> ><br>
> > With a bogus clock, power users could also write arbitrary markers with a<br>
> > newer date to solve the issue.<br>
> ><br>
><br>
> Hold up.<br>
><br>
> Wall clock times cannot be trusted. This is like a cardinal rule of writing<br>
> software in the real world. Yet this patch appears to not only rely on<br>
> local wall clock times being ordered but also relies on wall clocks from<br>
> different machines being ordered. That's a double no-no. Sorting by wall<br>
> clocks will lead to unexpected behavior which in the eyes of an end-user is<br>
> a bug.<br>
><br>
> Sorting by wall clocks is hardly ever a good idea. I have serious<br>
> reservations about using wall times to determine obsolescence marker<br>
> precedence.<br>
<br>
</div></div>The date idea was suggested by marmoute at the sprint. I was thinking about<br>
the physical offsets of markers in "obsstore" before.<br>
<br>
Using "date" for sorting is better than using physical offsets, because date<br>
is stored in markers and is a global thing, while offsets are local, which<br>
means you need to have some special non-trivial logic to deal with exchange.<br>
This reason alone is enough to convince me to switch from offsets.<br>
<br>
I'd note that for some systems like Zookeeper, clocks must be treated *very*<br>
seriously. But for the obsstore, clocks are not that important. Because the<br>
worst case is some visibility issue of commits. No data loss. No repo<br>
corruption.  No consistency issue. And could be fixed by power commands.<br></blockquote><div><br></div><div>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, 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.<br><br></div><div>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?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Not to mention most systems have sane clocks,</blockquote><div><br><div>This is dangerous to believe.<br><br>Anecdotally, I've experienced the following problems on just the machines I use day-to-day:<br><br></div><div>*
 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.<br><br></div><div>* 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.<br><br></div><div>*
 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.<br><br></div><div>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?<br><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> and most markers are date<br>
unrelated - only those cycles matter - cycles are uncommon.<br></blockquote><div><br></div><div>OK. Maybe that makes things better. In what scenarios can we get cycles? <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I think dsop summaried this up well:<br>
<br>
  Mar 13 10:57:26 <dsop> junw: so basically it boils down to: using date is<br>
  not perefct, it makes the solution easy and elegant and if clocks on<br>
  computers are wrong, the user might have a non-optimal user experience,<br>
  but we never loose data<br></blockquote><div><br></div><div>Strictly speaking, yes, we never lose data. But I'd argue that using the wrong data (changeset) inadvertently would be a massive bug and would create distrust in version control.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I've been thinking about the cycle problem for a long time and don't think<br>
there is a better solution practically. The current approach (tens of lines)<br>
is probably the most elegant thing I've ever contributed to the list. You're<br>
encouraged to suggest new ideas. But if the new idea is like some fancy<br>
format change plus some fancy conflict resolution during exchange, which<br>
sounds like thousands of lines, I think it's reasonable to say no-no to it.<br></blockquote><div><br></div><div>I agree the solution is simple, elegant, and probably works most of the time. But you've built this castle on an unstable foundation. Convince me it doesn't matter.<br><br></div><div>As for alternatives, a correct solution needs to refer to the marker it is replacing. Since cycles should be rare, can we record the full "replaced marker" data inline in the new marker? In local storage, that could be an integer offset to the marker. (Honestly, I don't fully understand the problem space. I just saw "sort by clocks" and all kinds of alarm bells went off.)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
> ><br>
> > The whole point of the series is to make it possible to reuse hashes.<br>
> > That's<br>
> > required for a nature user-experience of "hg unamend", "hg unstrip",<br>
> > "hg unabsorb" and maybe a general purposed "hg undo", etc.<br>
> ><br>
> > Yes, the undo reusing hash behavior may be solved in some other way, like<br>
> > striping the obsstore, or "inhibit". But I believe the obscycle is the most<br>
> > elegant, bug-free way. And it deals with exchange just well.<br>
> > ______________________________<wbr>_________________<br>
> > Mercurial-devel mailing list<br>
> > <a href="mailto:Mercurial-devel@mercurial-scm.org">Mercurial-devel@mercurial-scm.<wbr>org</a><br>
> > <a href="https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel" rel="noreferrer" target="_blank">https://www.mercurial-scm.org/<wbr>mailman/listinfo/mercurial-<wbr>devel</a><br>
> ><br>
</div></div></blockquote></div><br></div></div>