> On Mar 23, 2017, at 6:15 PM, Jun Wu <qu...@fb.com> 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. > > marmoute preferred date to offsets. And I agree because I don't have good > idea to handle the exchange headache (or I think it's better to be fully > automatic). > >> It still means a bad actor can produce a hard-to-defeat cycle (sort >> of), but it solves the clock skew issue. > > For clocks going backwards, we can detect that, say we get > maxdate = max(m.date for m in markers), then if we are going to write a > marker with date < maxdate, we could warn people, and/or write > (date+rand(0 to 1)) as a fake date. That would at least make non-exchange > experience always expected.
Could we default to using the current timestamp, but if there’s a member of the obsmarker chain we’re about to add to with a time ahead of our clock, we do (that time + rand(0,1)) as the time? Greg, does that alleviate most of your concern around using times? (This has the negative that in the presence of marker cycles time is somewhat a lie, but I think the overall ergonomics seem to be about right at least as a thought experiment...) _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel