A good web forge (~Gitlab) supporting Mercurial before Bitbucket's deadline (1st of June 2020)?

Thu Aug 29 16:56:28 UTC 2019

Hi,

On 8/29/19 3:53 PM, Nicolas Pinault via Mercurial wrote:
> 1) I'm not sure to understand Heptapod way of working.  Is this a
> native Mercurial based system or Git based system with a hg-git layer ?

This is primarily a native Mercurial system, with an additional
side-channel Git conversion for exposition to GitLab web application.

A more detailed answer can be read on the FAQ that I just published:

    https://heptapod.net/pages/faq.html#does-heptapod-use-git-under-the-hood

>
> 2) Here
> https://dev.heptapod.net/slides/2019-hg-paris/blob/branch/default/presentation.rst
> one can read
> """
> The Next Phase: Hg + Gitaly
> Starting now!
>
> Gitaly: abstraction layer for internal Git access
> Development of a Mercurial version
> No more hg-git
> much faster
> catching up onto current GitLab
> """
> Can you elaborate (I was not at the Mercurial conference) ?

Currently, Heptapod's GitLab mostly reads commits, diffs etc from the
above mentioned server-side Git repository (again not what your hg
client interacts with). Gitaly is a dedicated service developed by
GitLab to expose such Git contents. One of its benefits for regular
GitLab is that Git repositories don't have to be on the same file system
as the web application (lifting a major impediment for scability).
Recent GitLab versions have relied more and more on Gitaly.

Gitaly is not meant to provide an abstraction over the type of DVCS, yet
the way forward for Heptapod is to implement Gitaly for Mercurial
repositories. This should allow us to

- catch up on recent GitLab versions

- get rid of the internal Git conversion (much much better performance
by the way)

But to be honest, this effort has barely started, because the some other
topics have taken priority in the meanwhile. Notably, I was thinking
that we could wait a bit before we nail the detection of MR merges after
rebases etc, but this has become impossible to ignore in practice.

May I take this opportunity to state that help on the Gitaly front would
be much appreciated? Especially if there are developers around with gRPC
Python experience. This is a long term effort, but I think it can be
fun, and it can be gradually integrated (much like GitLab themselves did).

Regards,

> Nicolas
>
> Le 29/08/2019 à 15:09, Georges Racinet a écrit :
>>
>> Hi Pierre,
>>
>> (quoting you out of order, I hope you don't mind)
>>
>> On 8/26/19 11:01 PM, PIERRE AUGIER wrote:
>>>
>>> I can start a list of requirements for academics and open-source
>>> community projects (like PyPy or Mercurial :-)
>>>
>>> 0. Real Mercurial support (phases, evolve, topics, ...)
>>>
>> (...)
>>>
>>> The friendly fork of Gitlab https://heptapod.net/ seems very
>>> interesting. A very nice advantage is that Gitlab is the solution
>>> chosen by many academic institutions (for example my university :-).
>>> It is well known so Heptapod won't afraid people used to Github or
>>> Gitlab. And many "side services" (like https://codecov.io/) could
>>> just work out of the box.
>>>
>> Indeed Heptapod fulfills a good lot of the requirements on your list
>> already, and we have good hopes for some of the others (e.g.,
>> continuous integration). What we don't have right now is this:
>>
>>> 1. A free-of-charge-for-basic-service website
>>>
>>> The free-of-charge website is really important for students, "small"
>>> projects and academics. For example, as a teacher/researcher, I
>>> can't spend time to set up a server and an instance of ??? (it's
>>> really not my job, I don't know how to do it and I don't have time
>>> to learn this). It's important to be able to tell to
>>> students/colleagues that they can very easily create a personal
>>> account and their own repositories just with few clicks
>>>
>> All that makes sense. What we can do at this point is
>>
>> * provide access to people that want to try Heptapod on one of
>> Octobus' instances
>>
>> * provide some support to sysadmins (like your university's) that
>> want to setup an instance – you can tell them it's almost identical
>> to plain GitLab Docker install, by the way.
>>
>> As for actually starting a free-of-charge instance, we don't need
>> much more than to tighten a few bolts and screws on the technical
>> side. However, we'd need trusted volunteers to help with basic
>> administration and moderation, together with a way to compensate the
>> raw hosting costs once it's taken off.
>>
>> To summarize, that looks to me like it's achievable before BitBucket
>> shuts down the creation of new repositories if enough people join us
>> in the meanwhile.
>>
>> Regards,
>>
>> -- 
>> Georges Racinet
>> https://octobus.net
>> GPG: BF5456F4DC625443849B6E58EE20CA44EF691D39, sur serveurs publics
>>
>> _______________________________________________
>> Mercurial mailing list
>> Mercurial at mercurial-scm.org
>> https://www.mercurial-scm.org/mailman/listinfo/mercurial
>
>
> _______________________________________________
> Mercurial mailing list
> Mercurial at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial

-- 
Georges Racinet
https://octobus.net
GPG: BF5456F4DC625443849B6E58EE20CA44EF691D39, sur serveurs publics

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20190829/0e72a8b1/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20190829/0e72a8b1/attachment.asc>