Re: [jgit-dev] Ketch: multi-master replicated Git

[Shawn Pearce <spearce@xxxxxxxxxxx>]

On Wed, Jan 13, 2016 at 8:40 AM, Saša Živkov <zivkov@xxxxxxxxx> wrote:
> On Wed, Jan 13, 2016 at 3:54 PM, Shawn Pearce <spearce@xxxxxxxxxxx> wrote:
>>
>> Google is starting to contribute a new multi-master implementation,
>> calling it Git Ketch. Changes are on the Eclipse Gerrit[1].
>
>
> Great news!
> Thanks for contributing this work to JGit.
> Looks like replicated, multi-master, open source Gerrit will be soon a
> reality :-)

Hopefully. :-)

This is still very early work. Its months away from risking a
prototype server on, let alone a production server. But I think 2016
will be the year Gerrit ships a multi-master capable release.

> Do you also have a POC change in Gerrit which adds the "--ketch=LEADER"
> to its daemon program? Would something like that be useful at this early
> phase?

Not yet. There's a few things you want to do for Gerrit.

RefTreeDatabase needs an extension that is aware of Ketch so it can
convert BatchRefUpdates and RefUpdate objects to a Ketch Proposal and
send them to the KetchLeader. Once that's done any JGit application
(e.g. Gerrit) can make mutations to the repository.

This should actually be a small change someone else could try to
author. RefTreeDatabase is reasonably clean code at this point. Extend
it and override newBatchRefUpdate() to build a BatchRefUpdate that
passes the ReceiveCommands into a Proposal object and hands that to
the KetchLeader. The RefTreeUpdate also needs to know how to do this.
I think I messed up a few of the internal APIs between RefTreeUpdate
and RefTreeBatch that may require a bit of refactoring to make it
easier to recast the update in terms of a Proposal. But this should be
approachable by someone other than me.


Something similar to KetchPreReceive should be wired into
ReceiveCommits somewhere. When its performing a BatchRefUpdate to send
objects you want to run a spinner while waiting for the Proposal that
matches the BatchRefUpdate to execute. But that's a lot of change. May
be easier to find a way to plumb progress messages around somehow so
the `git push` user is entertained while a 3s operation runs on a
world-wide installation. :-\