Date: Mon, 12 Apr 2021 13:21:56 +0200 From: Michael Gmelin <freebsd@grem.de> To: Peter Jeremy <peter@rulingia.com> Cc: Helge Oldach <freebsd@oldach.net>, freebsd-ports@freebsd.org Subject: Re: Deprecation of portsnap (was: Proposed ports git transition schedule) Message-ID: <764055EB-373B-4A6F-845E-B083852F91B3@grem.de> In-Reply-To: <YHQq92JumUXOjOTg@server.rulingia.com> References: <YHQq92JumUXOjOTg@server.rulingia.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 12. Apr 2021, at 13:12, Peter Jeremy via freebsd-ports <freebsd-ports@f= reebsd.org> wrote: >=20 > =EF=BB=BFOn 2021-Apr-11 14:27:27 +0200, Helge Oldach <freebsd@oldach.net> w= rote: >> 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. >>=20 >> 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? >=20 > 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 wh= en 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. >=20 > Ignoring that, a "git up -ff" on a ports tree peaks with 2=C3=971GB proces= ses, > though it looks like the working set size might only be ~350MB. >=20 > --=20 > Peter Jeremy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?764055EB-373B-4A6F-845E-B083852F91B3>