jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: Conflict handling through rebasing branches
Date Fri, 18 Jan 2013 07:35:17 GMT

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.


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