Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 29 Dec 2016 11:44:20 +0100
From:      "O. Hartmann" <ohartmann@walstatt.org>
To:        blubee blubeeme <gurenchan@gmail.com>
Cc:        freebsd-current@freebsd.org
Subject:   Re: A question about updating src & ports
Message-ID:  <20161229114408.4dfdbb8e@thor.walstatt.dynvpn.de>
In-Reply-To: <CALM2mEm24Dx=HPfczjbhhVHo8Cok%2BrHAkRpihNbSEfJR_3P7vA@mail.gmail.com>
References:  <CALM2mEm24Dx=HPfczjbhhVHo8Cok%2BrHAkRpihNbSEfJR_3P7vA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/ut1ZX_HkfxGTeXPSZenB1dU
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Am Thu, 29 Dec 2016 18:11:38 +0800
blubee blubeeme <gurenchan@gmail.com> schrieb:

> Howdy
>=20
> I went through the process of building world for the first time, that was
> interesting but I got it. svn clean up prior object files, build world,
> kernel, etc.
>=20
> Okay that part is fine
>=20
> I have a question about keeping ports up to date, in the past I did
> portsnap fetch update to update the ports but since I totally deleted all
> the ports and used svn checkout to get the latest ports.
>=20
> Can I mix portsnap fetch update or should I just continue to use svn upda=
te
> /usr/ports
>=20
> Best,
> Owen

Well,

from my own experience I left the path of "portsnap" and stay with svn alon=
e. portsnap
tends to "flood" the /var filesystem with a tremendous number of files over=
 time. Each
time you issue "portsnap fetch update", a file appears in /var/portsnap - i=
t could be
that the files appear in /var/db, I can't remember. Deleting them with "rm =
-rf *" leaves
me then with an error from "rm": the argument line is to long due to the nu=
mber of files.
Therefore, I switched to svn.

Well, svn itself is pumping up /usr/ports/.svn where it keeps all logs. Dep=
ending on the
frequency of updates it grows. I do the same for /usr/src and by the time o=
f fetching
almost every day several times a day updates, the folder .svn is as large
as /usr/src itself in its pristine state when fetched initially. For
long-haul/long-running systems I'm concerned about the flood of data coming=
 in and
sometimes the filesystem is full. I avoid ZFS on build machines and use par=
titions
for /usr/src, /usr/obj and sibblings which saved my ass several times for n=
ow. ZFS is a
memory hog, on /usr/ports (which is on ZFS in mz scenario, the exclusion ..=
.), a "svn
update" can take up to 8 minutes on a 16GB, freshly rebooted box with a 3,4=
 Ghz XEON
IvyBridge CPU and a ZFS RAIDZ with 4 HDDs and SSD for ZIL and L2ARC.=20

On the other hand - I once tried to mix portsnap and svn and apart from any=
 theory it
worked a while and then it failed. That might be due to non-synchronisation=
 between
portsnap serving facilities and subversion repositories - which I would exp=
ect not to be
in sync withing femto seconds. So it might be wise to saty with one specifi=
c method - I
decided myself to keep it with svn.

Just my experience,

Kind regards,

Oliver
=20
--=20
O. Hartmann

Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr
Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.=
 4 BDSG).

--Sig_/ut1ZX_HkfxGTeXPSZenB1dU
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWGTpBAAKCRDS528fyFhY
lJD2Af9qQT0HO++SSYqGi0OuQxo3UWzS1VY/71Yx9ANGpuGVac/OcUMh4jnLcgj8
CnePpshRGJb7/+I4J3slshL7LogLAgCS4LLEf73aafUw5a2IxUn+fzVIkdlorwQ1
NMWF7rFbq57kdCQNs4xWrtiqHgGs7+HccTYzbVuUq/YHjm8vMuKc
=kt5U
-----END PGP SIGNATURE-----

--Sig_/ut1ZX_HkfxGTeXPSZenB1dU--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20161229114408.4dfdbb8e>