On 18.1.13 7:35, Jukka Zitting wrote:
Hi,
On Thu, Jan 17, 2013 at 7:15 PM, Michael Dürig <[email protected]> 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.
Exactly.
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.
Michael
