Re: [Gnu-arch-users] Re: cacherev policy script

[John A Meinel]

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