[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Re: cacherev policy script
From: |
John A Meinel |
Subject: |
Re: [Gnu-arch-users] Re: cacherev policy script |
Date: |
Thu, 18 Nov 2004 13:16:45 -0600 |
User-agent: |
Mozilla Thunderbird 0.9 (Windows/20041103) |
Miles Bader wrote:
On Thu, Nov 18, 2004 at 12:48:58PM -0500, Stefan Monnier wrote:
[...]
It's very dependendent on other properties of the protocol though.
When I (too rarely) make emacs cacherevs, I'm very careful to place them a
fair number of revisions before the latest, because if I don't, someone using
my tree to do _updates_ can get a cacherev, which is extremely horrible in
the case of emacs. This problem would go away if tla used smarter algorithm
to choose when to use cachrevs, of course... :-/
-Miles
Well, if you use replay you don't have that problem, and if you use a
revlib, it also prefers forward building over a cacherev. When does it
not prefer this? Does it build pristine trees differently?
I agree that tla could use a smarter building algorithm. I think
abentley agrees, he wrote the back-builder.
What are the current issues:
1) tla won't apply patches backward (so I have patch-135 I need 134, it
will build from 100 instead of backwards). I think abentley covered
this, but I'm not sure why it isn't integrated.
2) I have a very old version (say patch-1), and I'm doing a large update
(say to patch-200), there is a more efficient cachrev at patch-200, tla
will build from 1
3) I don't have any versions in my library (library is completely
empty), the archive is on patch-200, with a cachrev at 200. It will go
through the entire 200 patches looking for a parent in my revlib, when
it finishes, it will grab the cacherev. This is pretty expensive with
remote archives, as it is a full round trip each time. *I* would like
the behavior of "look for < 50 parents, if not found, use a cacherev".
So that the worst case behavior would be better.
4) In the case of looking for old revisions in your revlib, tla will not
cross archives (except for the immediate parent), but it will cross
categories in the same archive. Here is the test:
# create the base category.
mkdir revlib-builder
cd revlib-builder
tla init-tree test--revlib-builder--0
echo "file" > file.txt
tla add file.txt
tla import -S
# now add a few revisions
tla commit -s ""
tla commit -s ""
tla commit -s ""
tla commit -s ""
tla commit -s ""
# Now tag to a new category, and add a few revisions
tla tag -S test--revlib-builder--0 test--revlib-builder--1
cd ..
tla get test--revlib-builder--1 rvb-1
cd rvb-1
tla cacherev # We want a cacherev at base-0
tla commit -s ""
tla commit -s ""
tla commit -s ""
tla commit -s ""
tla commit -s ""
# Now clean out your revlib, I use a temp archive to not disturb other
# things. This guarantees nothing in the revlib
rm -rf $REVLIB/$ARCHIVE
tla library-add test--revlib-builder--0--base-0
tla changes # This has to build the test--revlib-builder--patch-n tree
* looking for address@hidden/other--dev--1--patch-2 to
compare with
* auto-adding address@hidden/other--dev--1--patch-2 to
greedy revision library /home/jfmeinel/.tla-revision-library
* searching ancestor revision in library in archive
address@hidden
* found ancestor revision in library
(address@hidden/other--dev--0--base-0)
* patching for this revision
(address@hidden/other--dev--1--patch-2)
* patching for revision
address@hidden/other--dev--0--patch-1
* patching for revision
address@hidden/other--dev--0--patch-2
* patching for revision
address@hidden/other--dev--0--patch-3
* patching for revision
address@hidden/other--dev--1--base-0
* patching for revision
address@hidden/other--dev--1--patch-1
* patching for revision
address@hidden/other--dev--1--patch-2
* comparing to address@hidden/other--dev--1--patch-2
Notice that it did search back to an old version. Which means that if I
have 500 revisions in the last version, and another 100 in the latest
version, even if I put a cacherev at the last patch, you will get 600
round-trips to the archive to determine there are no parent revisions in
your library.
So you can't just tag to a new version and have the parent search be
fast. I would argue that tla should still look across categories, but
should be smarter about not looking forever. Imagine the archive that
abentley showed, where it has 18,000 revisions in the *same* package.
Even if there are cacherevs on *every* revision, it will still do 18,000
round trips to the archive before it finds that you don't have any local
revision, and *then* it will get the last cacherev.
Obviously if no cachrev exists within the last 50 revisions, you have to
keep looking until you find one.
And maybe 50 should be adjusted based on whether it is a local archive,
versus a remote one. But *something* is needed for the degenerate cases.
I've only run into the problem with ~200 revisions, and I noticed it. So
I really wonder with stuff like the emacs tree with 700 revisions.
John
=:->
signature.asc
Description: OpenPGP digital signature