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

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

[Gnu-arch-users] Re: situations where cached revisions are not so good


From: Miles Bader
Subject: [Gnu-arch-users] Re: situations where cached revisions are not so good
Date: 27 Sep 2003 10:56:14 +0900

Jason McCarty <address@hidden> writes:
> I'm not sure anymore that summary-deltas would be a significant
> improvement over downloading all the revisions needed after a cachedrev.

For emacs they would be a _drastic_ improvement for people that already
have any kind of pristine/library entry.  A cached rev for emacs is
20MB, a typical summary delta would be a couple hundred KB (if that).

Note that when I think of a summary delta, I'm thinking of something
like:

    base-0      Cached-Rev, 20MB
    patch-1     Patch, 10KB
    ...
    patch-49    Patch, 20KB
    patch-50    Patch, 10KB
                Cached-Summary-Delta-0-50, 150KB
                Cached-Rev, 20MB
    patch-51    Patch, 15KB
    ...
    patch-99    Patch, 8KB
    patch-100   Patch, 5KB
                Cached-Summary-Delta-50-100, 120KB
                Cached-Rev, 20MB
    patch-51    Patch, 13KB
    ...

For a someone fetching a virgin tree, it would be better to pick the
closest cached rev, and then apply individual patches to get the exact
desired revision.  For someone that already has existing
pristine/library entries for emacs, it would better to choose an
appropriate chain of summary deltas, and then apply individual patches
as appropriate.

My thought was that the same tla comand (cacherev) could be used to
create the summary deltas.

Of course it would be nice if there was algorithm to pick the optimal
set of things to do based on existing trees/bandwidth/etc., but
probably heuristics could do alright too, at least better than the
current state...

-Miles
-- 
The secret to creativity is knowing how to hide your sources.
  --Albert Einstein




reply via email to

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