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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Pierre Augier

Hi,

After Bitbucket's announcement (https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket), I waited a bit to think about the situation. Now, I'd like to share my thoughts because I think we could have to give up with Mercurial.

From where do I speak? I'm a researcher in fluid mechanics, with a strong commitment in open-source development. in particular, I develop a suite of (Python) software for my scientific community (FluidDyn).

I also recently launched Transonic (https://bitbucket.org/fluiddyn/transonic), an open-source project potentially useful for many developers of scientific/numerical Python packages.

For the FluidDyn packages and Transonic, we use Mercurial (and I'm very happy with "modern" Mercurial, with evolve, topics and absorb!) and Bitbucket.

With my students, I also use Mercurial, because I think it still make (now, made?) sense for students not specialized in computer science to start with Mercurial and not Git. I try to summarize my reasoning about this choice in this post : http://www.legi.grenoble-inp.fr/people/Pierre.Augier/mercurial-as-a-great-version-source-control-management-tool-in-academics.html

However, with the end of Mercurial support by Bitbucket, my Mercurial choice becomes more and more difficult to defend... and with FluidDyn developers, we'll soon have to decide what we do with our Mercurial repositories on Bitbucket. The simplest solution (that I don't like, but which present several advantages) would be to just give up with Mercurial and use Gitlab (either with the main instance or with the instance officially proposed by my university https://gricad-gitlab.univ-grenoble-alpes.fr). I know that I would still be able to use hg with hg-git, but without topics/evolve/absorb, and other developers would surely use directly Git (which would not be so bad after all).

So I'm going to express my personal point of view on this issue. For open-source community projects, we **really** need a good web forge for Mercurial. Something similar to Gitlab, and with approximately the same features.

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, ...)

1. A free-of-charge-for-basic-service website using an open-source software that can also be used for self-hosting (something like Gitlab).

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.

2. Public and private repositories

3.0. Very simple (and free-of-charge) to create an account

3.1. Forks and pull requests from forks

With Github and Gitlab, it is really the standard path. People are so used to this method that we really need it.

4. not inefficient (not super slow to clone / push / pull small repositories)

5. A modern issue tracker

6. A simple solution for Continuous Integration (internal or external but integrated with the pull request mechanism).

7. Different plans at different prices. First plan (create/manage small repositories with a very small team, fork repositories, ...) has to be free-of-charge.

8. Various basic things like:

* hg log -G page

* README.rst / .md nicely formatted shown in the main page of the repository

Bonus:

- https push / pull (much simpler than ssh for new comers)

- A "where is my data / the material infrastructure" option for some sensible data

- Project teams to handle the write and admin permissions

- Community maintained

I realize that I ask a lot and that I basically describe something very similar to Gitlab for Mercurial. But to be honest, we really need a very good quality web forge, otherwise, I don't see how Mercurial can continue to be used by simple open-source projects (and continue to be learned outside of companies or big projects like PyPy).

Then there are a lot of questions, in particular:

- From where to start technically?


Sourcehut exists and it's already nice. But now it is very minimalist and it lacks some important features (for example an issue tracker, forks and pull requests). Moreover, it seems that people will have to pay even for basic accounts (we can't ask people to pay to send a pull request!).


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.


I guess there could be other technical solutions...

- Would it be technically feasible? Of course, it would be really nice to be able to launch a working version before Bitbucket's deadline (1st of June 2020, i.e. in less than one year)

- I have no idea of the costs of such service? Could something like this be financially sustainable?

- Would there be people / companies involved in the Mercurial community motivated to work on and/or finance such project?

- What will be the choices of open-source projects using Mercurial and hosted now on Bitbucket? For example PyPy?

Sorry for this long email, but I needed to share these thoughts and questions with Mercurial people.

Pierre

-- 
Pierre Augier - CR CNRS                 http://www.legi.grenoble-inp.fr
LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et Industriels
BP53, 38041 Grenoble Cedex, France                tel:+33.4.56.52.86.16


_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

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

Ludovic Chabant
Hi!

> Sourcehut exists and it's already nice. But now it is very minimalist
> and it lacks some important features (for example an issue tracker,
> forks and pull requests). Moreover, it seems that people will have to
> pay even for basic accounts (we can't ask people to pay to send a pull
> request!).

(disclaimer: I'm one of the hg.sr.ht maintainers)

UI-wise, I think it will always be minimalist, as that's the kind of stuff Drew (the main sourcehut dev) likes. Feature-wise, it's also minimalist but with the community (yours?) help, we can improve it. That said:

- There is an issue tracker, see todo.sr.ht. Right now all the sourcehut "services" are kind of scattered, which is why you might have missed it, but there are plans to have "project pages" on the main site (sr.ht) which let you gather those up under a common umbrella for a given project (see https://todo.sr.ht/~sircmpwn/sr.ht/131).

- We could add a "one-button-fork" but that's low priority, if even desirable (see second next point). You can already make your own fork by doing "hg clone URL1" and "hg push URL2" (where URL2 is an hg.sr.ht SSH URL... it will auto-create the repo in your profile).

- There won't be support for pull requests any time soon because the premise of sourcehut is to use email-based workflows. The reasoning behind it is that (among other things) it lets reviewers work on their patch queue offline, encourages them to try the patch, and lets them build advanced workflows and tools for handling large amounts of patches. Being email-based doesn't mean you can't have a nice web UI to follow what's going on, though (see https://lists.sr.ht/~emersion/mrsh-dev/%3C20180804160231.32283-1-sir%40cmpwn.com%3E). But of course that's not for everyone (just like pull-request-based workflows aren't for everyone either), so if that's a deal breaker for you, you can probably ignore sourcehut for the time being.

- A corollary of the previous point is that you don't need a fork to send patches. Hence the absence of a "create fork" button. You can just clone the repo locally and send your patches via "hg email" (see https://book.mercurial-scm.org/read/hgext.html#send-changes-via-email-with-the-patchbomb-extension). No extra steps needed! It's really a lot faster than with pull requests once you get the hang of it.

- Another corollary is that here's no need for using paid account to send patches.  Again, just clone the repo locally and start contributing.

If you have more questions, feel free to ping me or Drew on IRC (#srht) or on the sourcehut mailing list (https://lists.sr.ht/~sircmpwn/sr.ht-discuss).

Cheers!
_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

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

Malcolm Matalka

Ludovic Chabant <[hidden email]> writes:

> - Another corollary is that here's no need for using paid account to
> send patches.  Again, just clone the repo locally and start
> contributing.

And just to be specific: you don't need an account to email a mailing
list (unless that mailing list is explicitly limited to sourcehut
users).  And sr.ht is developing some nice features to figure out if an
email is a patch and provide specialized views on top of them.
_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

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

Georges Racinet-2
In reply to this post by Pierre Augier

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
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Nicolas Pinault via Mercurial
Hi,

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 ?

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) ?

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
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial


_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

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

Georges Racinet-2

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
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial


_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
-- 
Georges Racinet
https://octobus.net
GPG: BF5456F4DC625443849B6E58EE20CA44EF691D39, sur serveurs publics

_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Nicolas Pinault via Mercurial
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
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial


_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
-- 
Georges Racinet
https://octobus.net
GPG: BF5456F4DC625443849B6E58EE20CA44EF691D39, sur serveurs publics

_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial


_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

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

Brendan Barnwell
In reply to this post by Pierre Augier
        I was heartened to see this message and I hope something will come of
it.  In general I agree with what you mentioned as the desiderata.  For
me the key combination of features that made Bitbucket great were that
it offered:

1. unlimited
2. free
3. private
4. Mercurial repositories

        I feel there is a huge difference between having all of those features
and having any three of them.  In particular the ability to have
unlimited PRIVATE repositories is, I think, a huge benefit for people
using Hg for casual projects.  I have lots of projects that I'm working
on by myself or maybe with one or two other people, and I don't want to
make them publically available, but I'd still like to be able to have a
server somewhere that I can push and pull to so that I can work on
different computers.

        As you mentioned, adding HTTPS push to this list goes a long way toward
lowering the barriers to entry for beginners

        I realize that it's kind of a lot to ask of any service provider that
they offer free and unlimited repos, but I do think it is an important
point for providing a low-friction Hg solution for the masses.  I do
hope some other provider sees their way clear to filling the gap that
Bitbucket has left.

--
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is no
path, and leave a trail."
    --author unknown
_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

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

Steve Fink
On 9/12/19 10:04 PM, Brendan Barnwell wrote:

>     I was heartened to see this message and I hope something will come
> of it.  In general I agree with what you mentioned as the desiderata. 
> For me the key combination of features that made Bitbucket great were
> that it offered:
>
> 1. unlimited
> 2. free
> 3. private
> 4. Mercurial repositories
>
>     I feel there is a huge difference between having all of those
> features and having any three of them.  In particular the ability to
> have unlimited PRIVATE repositories is, I think, a huge benefit for
> people using Hg for casual projects.  I have lots of projects that I'm
> working on by myself or maybe with one or two other people, and I
> don't want to make them publically available, but I'd still like to be
> able to have a server somewhere that I can push and pull to so that I
> can work on different computers.

Just out of curiousity: why is #1 necessary for casual projects? I don't
know what specific limits are being referred to, but repository size and
change frequency and total bandwidth should all be pretty small for
casual projects.

Is it because of the possibility that a casual project turns serious,
and you wouldn't want to switch repository providers if that happens?
Though even that feels like a niche -- if a casual project turns
serious, then why keep it private? After all -- if it's private, then by
definition not many people can use it, so limits don't matter very much.

I can visualize other use cases that *would* want all four of the above,
but I find it harder to see why anyone would have the incentives to
support those. (eg your company wants its stuff to be private, and has
lots of developers hitting the repo -- why would anyone want to pay for
your hosting if it's invisible to the outside world?)

_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial
Reply | Threaded
Open this post in threaded view
|

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

Brendan Barnwell
On 2019-09-17 08:49, Steve Fink wrote:

> On 9/12/19 10:04 PM, Brendan Barnwell wrote:
>>     I was heartened to see this message and I hope something will come
>> of it.  In general I agree with what you mentioned as the desiderata.
>> For me the key combination of features that made Bitbucket great were
>> that it offered:
>>
>> 1. unlimited
>> 2. free
>> 3. private
>> 4. Mercurial repositories
>>
>>     I feel there is a huge difference between having all of those
>> features and having any three of them.  In particular the ability to
>> have unlimited PRIVATE repositories is, I think, a huge benefit for
>> people using Hg for casual projects.  I have lots of projects that I'm
>> working on by myself or maybe with one or two other people, and I
>> don't want to make them publically available, but I'd still like to be
>> able to have a server somewhere that I can push and pull to so that I
>> can work on different computers.
>
> Just out of curiousity: why is #1 necessary for casual projects? I don't
> know what specific limits are being referred to, but repository size and
> change frequency and total bandwidth should all be pretty small for
> casual projects.

        The main limitation I was thinking of is a limitation on the number of
repositories (or "projects" or whatever a given service calls them).
Some of the services I've been looking at since Bitbucket's announcement
have free or low-priced tiers that put a cap on the number of repos
(e.g., https://www.versionshelf.com/sign_up).  An overall limitation on
total size or bandwidth indeed would not be as bad.

        Some services also place a limit on the number of users who can
collaborate on private repos.  Depending on how this is calculated it
can also be a problem.  If the limit were number of users per repo that
might be okay, but some services (such as, I think, Bitbucket) count any
user with access to any of your private repos as "a user" that counts
agains the free plan limit.  So if you have five private projects each
with a different collaborator, you hit the five-user cap.

--
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is no
path, and leave a trail."
    --author unknown
_______________________________________________
Mercurial mailing list
[hidden email]
https://www.mercurial-scm.org/mailman/listinfo/mercurial