Simon Howkins <
sim...@symbian.org> wrote:
> We (Symbian) have seen Gerrit in action and we really like the features it
> provides, particularly the automation of applying the fix to the master
> branch when it's all approved/verified.
I'm glad you like it.
> However, we're using Mergurial, not Git, so Gerrit isn't something we can
> just deploy. We've thought about undertaking the work to make Gerrit work
> with Mercurial too, but that's a big step to take alone (but still not as
> big as migrating from hg to git for all our systems!).
>
> I can't find any information about this online at the moment, so...
>
> * Is anyone on this mailing list aware of such an adaptation in progress at
> the moment?
Its not being worked on.
> * Or under discussion?
> * Has it been discussed in the past, and if what came of it?
I've talked about it internally with Augie Fackler, who is one of the
Hg contributors, and also something of a fan of Gerrit Code Review.
Unfortunately that was held over a private IM session or something
so there really wasn't a record of it. Let me try to summarize
from memory:
- License:
Gerrit is under Apache License 2.0, at the time Hg was under GPLv2.
These aren't compatible licenses. However since that conversation,
I understand Hg has relicensed to GPLv2-or-later. This permits
using Hg under GPLv3, which is compatiable with APLv2.
- refs/changes:
Gerrit require the VCS to allow it to create a unique branch head
for every change it receives. In Git this is simple, we create
a new reference under the refs/changes/ namespace and we're done.
In Hg this requires multiple heads in the same repository, which
isn't very common. I don't know enough about Hg to know how to
implement that in a sane way for an Hg store.
- JGit assumptions:
Perhaps too much of the server side code assumes JGit is present
and can be used to implement certain actions. We'd have
to refactor this out into a VCS abstraction layer. Its not
impossible, its just a lot of effort.
- Hg on Jython:
Ideally we'd use Hg on Jython so we can avoid forking out from
the JVM. (Forking a running JVM isn't pretty.) I don't know
the status of Hg on Jython, is it fully functional?
> * Is portability between SCM tools something that's already factored into
> the design of Gerrit?
No, it wasn't factored into the design. Gerrit has been more
organically grown to meet immediate needs than it has been
designed to be fully flexible for improvements. We needed Git,
so we added Git.
> * Is it feasible at all?
Its feasible, but its a _lot_ of work. I don't want to discourage
you from doing it, I just want to make it clear that I think its a
pretty sizable effort, and isn't something that will be accomplished
in an afternoon of hacking.
> * Would anyone else in the Gerrit community like to contribute to that work?
I won't personally contribute on the Hg side, but I'm happy to help
with code reviews, and might help out with some of the refactoring
necessary to support this.