On Tue, Apr 6, 2010 at 11:03 AM, Tatu Saloranta wrote:
> On Tue, Apr 6, 2010 at 8:45 AM, Mike Malone wrote:
> >> As long as the conflict resolver knows that two writers each tried to
> >> increment, then it can increment twice. The conflict resolver must know
> >> about the semantics of "incremen
On Tue, Apr 6, 2010 at 9:11 AM, Paul Prescod wrote:
> This may be the blind leading the blind...
> On Mon, Apr 5, 2010 at 11:54 PM, Tatu Saloranta
> wrote:
>>...
>
>>
>> I think the key is that this is not automatic -- there is no general
>> mechanism for aggregating distinct modifications. Point
On Tue, Apr 6, 2010 at 8:45 AM, Mike Malone wrote:
>> As long as the conflict resolver knows that two writers each tried to
>> increment, then it can increment twice. The conflict resolver must know
>> about the semantics of "increment" or "decrement" or "string append" or
>> "binary patch" or wha
>
> As long as the conflict resolver knows that two writers each tried to
> increment, then it can increment twice. The conflict resolver must know
> about the semantics of "increment" or "decrement" or "string append" or
> "binary patch" or whatever other merge strategy you choose. You'll register
This may be the blind leading the blind...
On Mon, Apr 5, 2010 at 11:54 PM, Tatu Saloranta wrote:
>...
> I think the key is that this is not automatic -- there is no general
> mechanism for aggregating distinct modifications. Point being that you
> could choose one amongst right answers, but not
