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.
+1 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 MicroKernel. 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. BR, Jukka Zitting
