gnu-arch-users
[Top][All Lists]
Advanced

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

Re: [Gnu-arch-users] patch: automatic cacherev and smarter get


From: Mikhael Goikhman
Subject: Re: [Gnu-arch-users] patch: automatic cacherev and smarter get
Date: Wed, 23 Nov 2005 04:45:35 +0000
User-agent: Mutt/1.4.2.1i

On 22 Nov 2005 18:33:19 -0800, Derek Zhou wrote:
> 
> Mikhael Goikhman wrote:
> 
> > I have a question. If there is an automatic cacherev every 50
> > revisions, I suppose this happens on base-0, patch-50, patch-100 and
> > so on, so that if patch-123 is requested, there is a good estimation
> > that patch-100 is cacherev'd. Is this correct, or it may also
> > auto-cacherev patch-111?
> 
> Right now it just does 0, 50, 100, ... If patch-123 is requested, then
> there are two possible ways to fetch it:
> 1, if you happen to have a patch level between 51 and 122 in revlib or
> pristine, get that and patch on. 
> 1, otherwise, get the cacherev patch-100 and patch on

So, it seems you don't assign costs to any operations with revlib
(querying revision, fetching revision tree) and to patching itself.
These operations are only insignificant for remote archives.

Is the following correct? You query revlib revision and archive cacherev
at patch-123, then at patch-122,... after finding cacherev at patch-100
you only continue to query revlib revisions, until patch-51.

> > Another thing. If I understand correctly, you only assign cost to
> > applying a patch. But not to fetching different things from archive.
> > (Ideally, different costs for local and remote archives.)
> 
> Right now I try not to cross the archive boundary. So the tradeoff is
> really between fetching patches or fetching cacherev from the same
> archive.

There is also "querying cacherev". With many network setups/protocols,
this operation is almost as slow as "downloading patch". The high time
tla spends to query hundreds of possible cacherevs always annoyed me.
Now, when there is an educated guess about potential cacherevs, some
futher optimizations are possible probably.

Regards,
Mikhael.




reply via email to

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