[PATCH 4 of 4 V2] obsolete: allow cycles

[Kostia Balytskyi]

On 25/03/2017 08:20, Simon Farnsworth wrote:

> 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 <quark at 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?

How do we decide which of the different hashes represents the cycle stop?
E.g. I created a A<-B marker with "extra" H1, someone else cleated B->A marker
with "extra" H2, we exchanged, how do we decide which commit to use?
My understanding was that as long as H1 and H2 are universally oredered
(meaning dates), we know what to do, but without ordering (like hashes)
we do not. Am I missing something?

>