> On May 13, 2020, at 10:11 PM, John Franklin <[email protected]> wrote:
>
> On Apr 30, 2020, at 21:28, bch <[email protected]> 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
> [email protected]
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.
>
