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

[luca.milanesio@xxxxxxxxx]

> On 13 Jan 2016, at 23:27, Shawn Pearce <spearce@xxxxxxxxxxx> wrote:
> 
>> 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 could be easily plugged into Gerrit already now without affecting JGit, by simply implementing a receiveCommit listener, send and wait for a KetchLeader confirmation ... And in the meantime saying something useful to the user, like "what's the weather today? Bear with me ..."

Luca

> 
> 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. :-\
> _______________________________________________
> jgit-dev mailing list
> jgit-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/jgit-dev