Deprecation of portsnap (was: Proposed ports git transition schedule)

[Michael Gmelin]

> On 12. Apr 2021, at 13:12, Peter Jeremy via freebsd-ports <freebsd-ports at freebsd.org> wrote:
> 
> On 2021-Apr-11 14:27:27 +0200, Helge Oldach <freebsd at oldach.net> wrote:
>> Peter Jeremy via freebsd-ports wrote on Sun, 11 Apr 2021 00:52:11 +0200 (CEST):
>>> Following the SVN to GIT migration, portsnap is now the only practical
>>> way to use ports on a low-memory system.  I've done some experiments
>>> and standard git has a 2GB working set to checkout a ports tree.
>> 
>> However checking out is a one-time action with ports as there is only
>> one branch (switching frequently between main and quarterly is probably
>> not very sensible on a limited machine). git pull is significantly more
>> lightweight, I've just seen some 200M RSS. That should work well even on
>> a 512M machine. Probably much better than gitup in constrained memory?
> 
> Except that git will arbitrarily and randomly decide that it needs to
> run "gc" -

See https://git-scm.com/docs/git-gc for an explanation of how git decides when to run gc and how you can control it (e.g., by setting gc.auto to 0).

-m

> which is similarly extravagant in memory usage.  Last time
> I found one running, it thrashed that poor VM for 3 days.
> 
> Ignoring that, a "git up -ff" on a ports tree peaks with 2×1GB processes,
> though it looks like the working set size might only be ~350MB.
> 
> -- 
> Peter Jeremy