[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: Managing smart fixed-size library

From: Mikhael Goikhman
Subject: Re: [Gnu-arch-users] Re: Managing smart fixed-size library
Date: Tue, 4 May 2004 23:26:40 +0000
User-agent: Mutt/

On 04 May 2004 17:13:14 -0400, Stefan Monnier wrote:
> > I.e., what is the mathematical way to say tla--devo--1.2--patch-113 is
> > more important than tla--devo--1.2--patch-25 and less important than,
> > say, address@hidden/linus--mainline--2.6--patch-6?
> I'd take "distance to the previous revision".
> This is based on the assumption that reconstructing revision N takes time
> proportional to the distance between N and the previous revision in the
> library (i.e. time propoertional to the number of patches to apply),
> and that any revision is just as likely to be requested as any other.

So, what would be your list of revisions from the parent message to
remove in order to aliminate the 100Mb shortage? :)

> The first assumption seems about right.  The second is probably wrong
> because more recent revisions are more likely to be requested than very
> old ones.

For this specific interface, the first (base-0) and the last (moving)
revisions are probably the most accessible ones. Other then these 2, the
recent revisions are much more likely to be requested. I would also
expect, at least revision creation/access times to be participated in the
ideal formula.

And here is something that just happened. Someone browsed the archives
causing some revisions to be added to the library, and its disk size fell
from 2.7Gb to 2.4Gb. Of course, hardlinks rule, but they also make the
whole thing less predictable. So, keeping both patch-1237 and patch-1238
is not very expensive after all.

Other ideas (or complete implementations) for a generic function to sort
library revisions by their "importance" given the disk quota constraint?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]