On 23/03/2017 22:15, Jun Wu wrote:
Excerpts from Augie Fackler's message of 2017-03-23 17:53:39 -0400:
On Wed, Mar 22, 2017 at 1:42 AM, Jun Wu <qu...@fb.com> wrote:
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
If "markers being replaced" are explicitly recorded, you will miss remote
markers that can be possibly replaced because you don't know them at the
time appending a new local marker. So you end up with some "conflict
resolution" logic during exchange.
That is not very different from just using the offsets - since obsstore is
append-only, new markers just "replace" old ones (I don't think there is an
exception that the newly added marker is intended to be replaced by a
previous one when working locally). It's simpler but has the same exchange
headache.
I wonder: could we get away from using dates by putting some kind of
generation number in the marker? So if a marker would create a cycle,
we increment its generation number relative to the previous highest
value in the cycle.
The problem is you don't know if a marker will create a cycle (or should
invalidate another marker), because remote markers are unknown. If you do
that during exchange, it makes exchange more complex.
I think that is not very different from just using the offsets.
Basically, if the new filed which is meant to be spread globally, date is
probably the best option. If it is not meant to be spread globally, offset
is already a decent choice, without format change. But offsets brings up
the exchange headache.
A thought experiment, to tease out concerns here; if we replaced the use
of date with hashfunc(marker) (where hashfunc is a randomly chosen
crypto hash), would people still have concerns?
In other words, if we take the semantics of "date" away, and treat
"date" as a random number that happens to always exist, do people's
concerns still hold water?
--
Simon Farnsworth
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
