jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mueller <muel...@adobe.com>
Subject Re: Conflict handling through rebasing branches
Date Fri, 18 Jan 2013 08:59:13 GMT

Do we have any real-world data about how many conflicts we typically get?
I would rather avoid adding a complex mechanism for something that occurs
very rarely. Also, why do we need to merge conflicts, and not just throw
the exception to the client? What kind of conflicts can be merged, how
common are they, and do they really need to be merged? The reason I ask is
that in the database world I have never heard about merging conflicts.
Instead, typically locks are used (even in PostgreSQL and Oracle that
support MVCC).


On 1/18/13 8:35 AM, "Jukka Zitting" <jukka.zitting@gmail.com> wrote:

>On Thu, Jan 17, 2013 at 7:15 PM, Michael Dürig <mduerig@apache.org> wrote:
>> The core idea is to try to resolve all conflicts in a branch through
>> rebasing it on top of the current trunk. After successfully rebasing a
>> branch, merging it to trunk is as simple as fast forwarding the head of
>> trunk to the head of the branch.
>In general, instead of throwing an exception (especially a generic one
>indistinguishable from other problems), I'd prefer for commit or merge
>to rather just return the revision of the new partially rebased
>branch, together with the appropriate conflict markers. The client
>would then have a chance to resolve those conflicts and re-merge using
>higher level context information than what's available in the
>The use of "atomic" in the pseudo-code is still a bit troublesome in
>terms of fully distributed operation, though for now I'd be fine with
>it as long as the critical section can be kept really small (as it is
>in the pseudo-code).
>An extension for a bit more write-concurrency would be to have each
>cluster node to maintain their own headRevision as essentially a local
>master branch of the global state of the repository. Any local changes
>would first get merged to that local master branch before being pushed
>to update the global headRevision. The main problem with such a
>mechanism is that there may be no good way to resolve conflicts. One
>potential solution would be to order the cluster nodes in some
>hierarchy of increased authority. Changes from nodes with higher
>authority would always override concurrent changes coming from below,
>with a single master node or (preferably) a small fully synchronized
>cluster acting as the ultimate authority. A client that wants to
>ensure that its changes won't get accidentally overwritten by other
>clients could write directly to that master, while others that don't
>require such guarantees could gain extra write concurrency by
>committing their changes to other cluster nodes with lower authority.
>Jukka Zitting

View raw message