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. 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@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
