Message-ID: <419CF51D.1020709@arbash-meinel.com>
Date: Thu, 18 Nov 2004 13:16:45 -0600
From: John A Meinel <john@arbash-meinel.com>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
MIME-Version: 1.0
To: Miles Bader <miles@gnu.org>
Subject: Re: [Gnu-arch-users] Re: cacherev policy script
References: <pan.2004.11.18.13.23.45.365921@progsoc.org>	<jwv3bz7rqxk.fsf-monnier+gmane.comp.version-control.arch.user@gnu.org>
	<20041118183448.GA23898@fencepost>
In-Reply-To: <20041118183448.GA23898@fencepost>
Cc: gnu-arch-users@gnu.org, Stefan Monnier <monnier@iro.umontreal.ca>
Precedence: list
Content-Type: multipart/mixed; boundary="===============0998055676=="
Sender: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Errors-To: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Status: RO
Content-Length: 6391
Lines: 169
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============0998055676==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enig61F644A74DDBDA523E7414DF"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig61F644A74DDBDA523E7414DF
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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 test@arbash-meinel.com--test/other--dev--1--patch-2 to 
compare with
   * auto-adding test@arbash-meinel.com--test/other--dev--1--patch-2 to 
greedy revision library /home/jfmeinel/.tla-revision-library
   * searching ancestor revision in library in archive 
test@arbash-meinel.com--test
   * found ancestor revision in library 
(test@arbash-meinel.com--test/other--dev--0--base-0)
   * patching for this revision 
(test@arbash-meinel.com--test/other--dev--1--patch-2)
   * patching for revision 
test@arbash-meinel.com--test/other--dev--0--patch-1
   * patching for revision 
test@arbash-meinel.com--test/other--dev--0--patch-2
   * patching for revision 
test@arbash-meinel.com--test/other--dev--0--patch-3
   * patching for revision 
test@arbash-meinel.com--test/other--dev--1--base-0
   * patching for revision 
test@arbash-meinel.com--test/other--dev--1--patch-1
   * patching for revision 
test@arbash-meinel.com--test/other--dev--1--patch-2
   * comparing to test@arbash-meinel.com--test/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
=:->

--------------enig61F644A74DDBDA523E7414DF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBnPUdJdeBCYSNAAMRAmZeAJ0WdbZVK/QLAu1+TivVaDIh7g4yywCgjy5V
Ijy4gAZu/GsXYFs5/VQxdlc=
=2Q5/
-----END PGP SIGNATURE-----

--------------enig61F644A74DDBDA523E7414DF--


--===============0998055676==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@gnu.org
http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/
--===============0998055676==--