[PATCH 4 of 4 V2] obsolete: allow cycles

Gregory Szorc gregory.szorc at gmail.com
Tue Mar 21 22:32:06 EDT 2017


On Tue, Mar 21, 2017 at 3:15 PM, Jun Wu <quark at fb.com> wrote:

> Excerpts from Augie Fackler's message of 2017-03-21 18:03:33 -0400:
> > > As long as exchange sends dates, markers are globally ordered, and they
> > > behave no different then the local case.
> > >
> > > Say Alice has A -> B created on date1, Bob has B -> A with date2. If
> date2 >
> > > date1, Bob wins. The time of pulling or the pull direction does not
> matter.
> > > Only the global version (date) matters. If date2 == date1, two markers
> > > "cancel out" and both A and B become visible.  Previously no matter
> what the
> > > dates are, A and B are both permanently invisible.
> >
> > I do worry a little about someone with a bogus clock years in the
> > future pumping out malicious nodes that can't be overridden, but I
> > suppose in that case your "way out" is that you perturb the hash of
> > the revision(s) you want to keep. Seem good enough?
>
> With a bogus clock, power users could also write arbitrary markers with a
> newer date to solve the issue.
>

Hold up.

Wall clock times cannot be trusted. This is like a cardinal rule of writing
software in the real world. Yet this patch appears to not only rely on
local wall clock times being ordered but also relies on wall clocks from
different machines being ordered. That's a double no-no. Sorting by wall
clocks will lead to unexpected behavior which in the eyes of an end-user is
a bug.

Sorting by wall clocks is hardly ever a good idea. I have serious
reservations about using wall times to determine obsolescence marker
precedence.


>
> The whole point of the series is to make it possible to reuse hashes.
> That's
> required for a nature user-experience of "hg unamend", "hg unstrip",
> "hg unabsorb" and maybe a general purposed "hg undo", etc.
>
> Yes, the undo reusing hash behavior may be solved in some other way, like
> striping the obsstore, or "inhibit". But I believe the obscycle is the most
> elegant, bug-free way. And it deals with exchange just well.
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170321/dd205a0c/attachment.html>


More information about the Mercurial-devel mailing list