Date: Mon, 15 Nov 2004 02:44:24 +0100 From: Benjamin Lutz <benlutz@datacomm.ch> To: freebsd-ports@freebsd.org Subject: Re: HEADSUP: INDEX[-5] files were removed from CVS. Message-ID: <200411150244.27804.benlutz@datacomm.ch> In-Reply-To: <Pine.LNX.4.44.0411141649030.6593-100000@pancho> References: <Pine.LNX.4.44.0411141649030.6593-100000@pancho>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart2085011.bk7D0CqmqU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > 1. make fetchindex will get you an INDEX that is only a day or so old. > Formerly, it was weeks or months old. (The fact that any of the > tools actually allowed, e.g., port upgrades with one so out-of-date > was more blind luck than anything else). Oh, didn't know that. That's actually very nice. > 2. Having INDEX in CVS creates immense repository bloat, which has > other side-effect (bandwidth load on the cvsup servers, for an > example). If you look at the CVSweb page for INDEX and click on > 'diff two versions', you'll see just how immense the diffs got. > 3. One could argue that, philosophically, that anytime you check a > database into a source control system, one is already doing > something that is philosophically wrong -- you're using a tool for > a purpose that it is not designed for and, at best, ill-suited for. Thinking about it, keeping the INDEX up to date should be trivial. INDEX=20 only gets updated when a port is changed, and only those lines affected=20 by that port can be changed in the INDEX. Of course, you might now say=20 that the bloat will be the same, it'll just be distributed into much=20 smaller parts. Aren't we running into the same problem though with the=20 vuxml port? About every time I browse freshports, I see at least one=20 vuxml update. > There is an INDEX tinderbox that is feeding 'make fetchindex'. It runs > continually. [...]=20 > So the idea of all this was to get away from 'INDEX file that works > but is only updated occasionally' to 'INDEX file that works and is > always up-to-date'. Alright, I see that this is actually a very nice solution. A question,=20 however: are there mirrors available, in case the server is not=20 reachable? (Besides, it didn't seem very fast earlier - just tested now,=20 it's much faster.) Personally, I can see now how having a dedicated INDEX server is more=20 efficient than keeping it in CVS, however my first reaction was negative,=20 mostly because of the lack of information (the HEADSUP was very terse,=20 and the first few mails in this thread weren't that insightful either).=20 Had you held the discussion in public, I'd have been able to follow the=20 thread (I'm sure all pros and cons were mentioned), which would have been=20 helpful. Granted, by making the discussion private, you avoid the=20 bikeshed problem. May I ask then that such threads are made at least=20 world-readable?=20 Benjamin --nextPart2085011.bk7D0CqmqU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBmAn7gShs4qbRdeQRAhOTAJ0T8XRqRKu7zJEM8eE2oUf/8zkUYwCeI6ed hK3lG1vwDVqIX3ehC+nxF2E= =s6qO -----END PGP SIGNATURE----- --nextPart2085011.bk7D0CqmqU--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200411150244.27804.benlutz>