Date: Mon, 11 Jan 2021 14:44:59 +0000 From: Matthew Seaman <matthew@FreeBSD.org> To: Erwan David <erwan@rail.eu.org>, freebsd-questions@freebsd.org Subject: Re: github ports Message-ID: <1746973c-e7c0-9ce3-a3cd-12ba239c597a@FreeBSD.org> In-Reply-To: <2c921d94-98dc-4916-6b1b-c3c2d2001932@rail.eu.org> References: <mailman.98.1610366402.21235.freebsd-questions@freebsd.org> <94ddb7c7d79c1614761fee4c28aaf367.squirrel@webmail.harte-lyne.ca> <2c921d94-98dc-4916-6b1b-c3c2d2001932@rail.eu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/01/2021 14:17, Erwan David wrote:
> But a big drawback is that as defauklt you get the whole history, which
> the moajority of us do not need and that some people cannot handle (not
> enough space, not enough bandwidth).
If you do a shallow clone of the repository (as Steve suggested
upthread) eg:
git clone --depth 1 --single-branch
git@github.com:freebsd/freebsd-ports.git
then the amount of disk space used should be roughly similar to what
you'ld use for portsnap(8) (including the bits portsnap uses under /var
as well as what's in /usr/ports). At least, extrapolating from some
investigations done comparing freebsd-update(8) and a similar shallow
clone of the src repository.
Tools like gitup will effectively do this sort of checkout for you. (In
ports as net/gitup, but beware: it's so new the paint is still wet, and
it probably has quite a bit of debugging still to do before it is
production ready.) gitup has been proposed as a possible BSD-licensed
tool to be bundled with the OS as a native way to pull down the system,
ports and other sources. There's also OpenBSD's 'got' which uses the
same repository format as `git` but assumes the sort of development
process the OpenBSD people use currently.
The first clone of the repo will be pretty bandwidth intensive, and also
not something you can restart from where you got to if your session gets
interrupted in the middle. There are plans afoot to supply snapshots of
the repositories as tarballs that you can pull down via fetch(8), which
will support resuming a download. That might not be available for ports
until after the ports cuts over from SVN though.
Subsequently updating via `git pull` should be pretty bandwidth
efficient -- you will literally download the exact changes needed to
take your existing checkout to the latest version from the upstream repo.
Over time, as you repeatedly `git pull` the disk usage will tend to
creep up a bit, but you can use `git gc --aggressive` to garbage collect
and minimize disk space usage.
Cheers,
Matthew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1746973c-e7c0-9ce3-a3cd-12ba239c597a>