Re: github.com/NetBSD/src 5 days old?

[matthew sporleder <msporleder%gmail.com@localhost>]

> On May 13, 2020, at 10:11 PM, John Franklin <franklin%elfie.org@localhost> wrote:
> 
> On Apr 30, 2020, at 21:28, bch <brad.harder%gmail.com@localhost> wrote:
>> 
>> I thought the plan to move to HG hasn't been finalised yet, am I missing something?  Plus, why HG and not Fossil, if the end-result consumption is via Git anyways?
>> 
>> Last I heard fossil had scaling issues due to the large number of artifacts that needed to be tracked. I may be able to trawl notes and find some particulars, or Joerg may be able to comment from memory on the technical aspects.
>> 
>> 
>> I was really hopeful for fossil as a solution as it seems really sane for many reasons:
>> 1) good user interface(s)
>> 2) good, novel ticket handling
>> 3) sane architecture
>> 4) portable C implementation
>> 5) BSD license 
>> 
>> I think in the end though Joerg reckoned the scalability issue was too much.
> 
> There are scalability issues with Mercurial, too.  I cloned NetBSD src on a 1GB RAM, 1GB swap, 4 CPU VM (Debian Buster) using git from the GitHub project and from anonhg.netbsd.org.
> 
> Git consumed 675MB of memory at its peak, and took 4m38s.  
> 
> Cloning with hg from anonhg.netbsd.org consumes all RAM and all swap before the OOM killer takes it out.  
> 
> Upping the memory to 2GB RAM (still 1GB swap) gets further along, to the point where hg forks into $(CPU_COUNT) processes for “updating to bookmark @ on branch trunk” before the OOM killer takes it out.  
> 
> Finally, 2GB RAM and 1GB swap, and enabling vm.overcommit_memory was enough to let hg finish in 17m52s.
> 
> jf
> -- 
> John Franklin
> franklin%elfie.org@localhost

This argument does not work. I went through the same goalpost moving exercise years ago and martin@ even got some efficiency patches into git as a result, but the super low memory shallow clone is not even good enough. 
>