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
