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
