HEADSUP: INDEX[-5] files were removed from CVS.
benlutz at datacomm.ch
Sun Nov 14 17:44:30 PST 2004
> 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
only gets updated when a port is changed, and only those lines affected
by that port can be changed in the INDEX. Of course, you might now say
that the bloat will be the same, it'll just be distributed into much
smaller parts. Aren't we running into the same problem though with the
vuxml port? About every time I browse freshports, I see at least one
> There is an INDEX tinderbox that is feeding 'make fetchindex'. It runs
> 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,
however: are there mirrors available, in case the server is not
reachable? (Besides, it didn't seem very fast earlier - just tested now,
it's much faster.)
Personally, I can see now how having a dedicated INDEX server is more
efficient than keeping it in CVS, however my first reaction was negative,
mostly because of the lack of information (the HEADSUP was very terse,
and the first few mails in this thread weren't that insightful either).
Had you held the discussion in public, I'd have been able to follow the
thread (I'm sure all pros and cons were mentioned), which would have been
helpful. Granted, by making the discussion private, you avoid the
bikeshed problem. May I ask then that such threads are made at least
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20041115/84ab10c2/attachment.bin
More information about the freebsd-ports