Thanks Georges for your explanations.
Le 29/08/2019 à 18:56, Georges Racinet a écrit :
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
[email protected]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
_______________________________________________
Mercurial mailing list
[email protected]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
--
Georges Racinet
https://octobus.net
GPG: BF5456F4DC625443849B6E58EE20CA44EF691D39, sur serveurs publics
_______________________________________________
Mercurial mailing list
[email protected]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
_______________________________________________
Mercurial mailing list
[email protected]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
