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. It still means a bad actor can produce a hard-to-defeat cycle (sort of), but it solves the clock skew issue. _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
