jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: Conflict handling through rebasing branches
Date Fri, 18 Jan 2013 09:37:47 GMT

On 18.1.13 7:35, Jukka Zitting wrote:
> Hi,
> 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 the
>> trunk to the head of the branch.


> 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).

I didn't mean this mechanism to be used globally but rather for a single 
cluster node only. For cluster sync. I was more thinking along the lines 
you sketch below.

> 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.

Or add the same kind of conflict annotations and rely on clients to 
resolve those. Such a client could well be a human. At least initially 
and/or partially. As Thomas notes, we don't have much experience with 
what kind of conflicts to expect and how often each type of conflict 
would appear. Since conflict handlers are plug-able in oak--core, such 
an approach would allow us to gain this experience and implement 
specific automated resolution algorithms tailored to specific settings 
as it turns out to be necessary.

On top of that, specific/custom applications might lead to new classes 
of conflicts. These could also be handled through specific/custom 
algorithms as it turns out to be necessary.


View raw message