It's configurable. Depot administrators can determine how much history they would like to keep. Presently, the logs are stored in units of hours of change. There's no reason why we couldn't also implement a policy that is based upon disk space used, though.
Once the maximum number of logs has been reached, we delete the oldest when we have to create a new logfile. Clients whose updates have become prehistoric must download a new catalog. Logs of deltas are kept separately from the current catalog. -j On Tue, Dec 04, 2007 at 06:29:06PM -0800, Chris Quenelle wrote: > I can't tell from the source or the BZ what your scalability plan is. > Once I have a bazillion megabytes of catalog history, how do I > reset it? Is it stored on the server as deltas and also as a complete file? > (Only looking at the 10,000 foot level here, I'm not familiar with the source) > > --chris > > > [EMAIL PROTECTED] wrote: > > The following webrev implements an incremental catalog update mechanism. > > As the size of the catalog increases over time, we'll save bandwidth and > > processing power if clients download a subset of changes to the catalog. > > Otherwise, clients would download an entire catalog on each refresh, > > probably wasting a lot of extra information. > > > > The webrev is here: > > > > http://cr.opensolaris.org/~johansen/webrev-cat-inc/index.html > > > > -j > > _______________________________________________ > > pkg-discuss mailing list > > [email protected] > > http://mail.opensolaris.org/mailman/listinfo/pkg-discuss > _______________________________________________ > pkg-discuss mailing list > [email protected] > http://mail.opensolaris.org/mailman/listinfo/pkg-discuss _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
