On 18.1.13 9:57, Jukka Zitting wrote:
Hi,

On Thu, Jan 17, 2013 at 7:15 PM, Michael Dürig <[email protected]> wrote:
int merge(branch) {
     while(true) {
         if (!rebase(branch)) {
             throw new MicroKernelException("merge conflict");
         }

         atomic {
             if (branch.baseRevision == trunk.headRevision) {
                 trunk.headRevision = branch.headRevision
                 return trunk.headRevision;
             }
         }
     }
}

One thing that came up already earlier, but should be reiterated here:
We have commit hooks that update indexes and possibly other
repository-wide content structures. It is quite likely for these to
cause merge conflicts. Also, the rebase operation may end up
invalidating some content constraints, so it should be possible to
re-run validators between the rebase operation and the final
headRevision update.

Thanks for the heads-up/reminder. Yes, I figure we should then not do an implicit rebase in merge(branch) but rather rely on the caller doing that. merge() and commit() could then simply fail with a conflict error when the changes are not based on the latest trunk. This makes the whole logic in Microkernel even easier and keeps conflict detection/annotation strictly in one single place.


Another, more minor point is that the loop above will behave badly if
the system is already overloaded and can't process merges as fast as
requested. A retry limit that causes the operation to fail after a
fixed amount of time would be safer.

I left this out to keep things simple. But taking this further we might even think of some kind of exponential back-off to take some load of a busy system.

[...]


The trouble here is that the commit hooks are in oak-core, so we'd
need to have oak-core instead of the MicroKernel be in charge of this
coordinating this work. One way of doing it would be to expose the
rebase() operation as a part of the MicroKernel API and to require
merge() and commit() to simply reject all changes that aren't based on
the latest head revision.

Right. See above ;-)

Michael


BR,

Jukka Zitting

Reply via email to