Message-ID: <41A7520C.3060808@arbash-meinel.com>
Date: Fri, 26 Nov 2004 09:55:56 -0600
From: John A Meinel <john@arbash-meinel.com>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
MIME-Version: 1.0
To: Andre Kuehne <andre.kuehne@gmx.net>
Subject: Re: [Gnu-arch-users] Improving Archive Cached Revisions
References: <20041126151216.GA8542@aku>
In-Reply-To: <20041126151216.GA8542@aku>
Cc: gnu-arch-users@gnu.org
Precedence: list
Content-Type: multipart/mixed; boundary="===============0189632318=="
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: 3139
Lines: 91
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============0189632318==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="------------enigEDC7CC3116D929A16F13EE36"

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

Andre Kuehne wrote:
> Hey guys,
> 
> The current Archive Cached Revisions implementation seems a little brute force
> to me. A logical step to a more flexible solution would be something like this:
> 
> "tla cacherev --level 0"
>     standard cached rev (full backup)
> "tla cacherev --level 1"
>     cached rev is a changeset from the last level 0 cached rev
> "tla cacherev --level 2"
>     ...
> 
> This would be especially helpful for large projects with lots of small
> changesets, but also in general. Tom's maxime that disk space is cheap
> (http://regexps.srparish.net/www/arch-tech.html#cheapdisk) doesn't mean
> you have to throw it away ;)
> 
> (If this was discussed already, some hint would be nice.)
> 
> Regards
> 

Actually, there is work going on about "deltas". Basically after 
n-changsets you can summarize it into a delta.

There has been quite a bit of discussion about the best way to implement 
this (hence why it isn't really done yet). Depending on the strategy, 
you can make them automatically generated, rather than requiring the 
user to specify them. If you make them automatic, then the routines that 
  do "get" can plan for them to be there.

One of the ideas was to create deltas for the 2^n revisions, so from a 
given revision, you can jump to the closest power of 2, effectively 
changing the linear patching with kind of a "binary search". Another 
idea was to create a back-bone of patches (like every 10), such that you 
have to apply linear patches to the nearest 10, but then you have a 
delta for all other 10's. So going from 7-102 would be
7,8,9,10,100,101,102, or possibly
7,8,9,10,20,30,40,50,60,70,80,90,100,101,102

Mostly to say, there is work being done there, it's just trying to 
figure out how to do it right that is delaying it.

John
=:->

--------------enigEDC7CC3116D929A16F13EE36
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

iD8DBQFBp1IPJdeBCYSNAAMRAre+AJ42+LvQSJuMvG8YNNI2WeX6z4llawCbBp6R
dv0hjA8ylUIVR2hT/vOz0FA=
=d28B
-----END PGP SIGNATURE-----

--------------enigEDC7CC3116D929A16F13EE36--


--===============0189632318==
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/
--===============0189632318==--