HEADSUP: INDEX[-5] files were removed from CVS.

[Benjamin Lutz]

> 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 
vuxml update.

> There is an INDEX tinderbox that is feeding 'make fetchindex'.  It runs
> continually.
[...] 
> 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 
world-readable? 

Benjamin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20041115/84ab10c2/attachment.bin