Hi, although I did not have the opportunity to jump in as planned I'm still
following changes and had some thoughts about that as well.

On Tue, Dec 18, 2012 at 4:51 PM, Michael Dürig <mdue...@apache.org> wrote:

>
> Right. However, degrading moves to remove/add node operations limits the
> size of sub trees which can be moved: if the moved sub tree (serialised to
> json add node operations) do not fit into heap, moves wont work at all.
>

When reading about splitting up a move operation in an add and a remove
operation I realized that automatic mergin might  lead to strange
constellations. If a node is moved and the creation did work while the
removal ended in a conflict (worst case: to concurrent moves) the create
would be performed without any annotation, so it is not that easy to
perform a client side resolution  without the awareness of a dedicated move
operation.

IMHO a commit that needs a merge should always fail but return the
necessary diff-information for client side resolution. This information
could either be in a way that allow the client just to "accept" a
mergeproposal or for unresolvable clients having the oportunity of
implementing a "mine"-"theirs" resolution logic. That way it is up to the
client to define how relaxed the system should behave. The (core) API could
even give the tooling to autoaccept or sequentially accept mergeproposals,
so the remaining implementationeffort for a client/binding can be lowered.

Hope I did get everything right and my thoughts do not irritate to much.

Best regards
Dominik

Reply via email to