Re: [Gnu-arch-users] a brief note on "delta compression"

[Matthieu Moy]

Tom Lord <address@hidden> writes:

> Interestingly enough, though -- nobody has bothered yet.  Why not?  I
> As far as I can tell, it's because 90+% of the time arch's facilities
> for archive-cached revisions and revision libraries solve the same
> problem, better, and more simply, albeit at the cost of more disk
> space.  While arch's alternatives use a little more disk space, in
> dollar terms, the excess is trivial.  Simpler is better, in this case.

But they could be complementary. 

The approach here should be similar to what sysadmins do with backups.
Full backups  are the equivalent of  cachedrevs, and delta-compression
are the incremental backup. 

Having one  cachedrev for each patch  multiple of 100, and  a 10-patch
delta for each multiple of 10 would make, for example,

$ tla get ....-patch-845
* Getting cached revision 800
* Patching for revision 810
* Patching for revision 820
* Patching for revision 830
* Patching for revision 840
* Patching for revision 841
* Patching for revision 842
* Patching for revision 843
* Patching for revision 844
* Patching for revision 845

Or  even, with  a  level  2 delta-compression  :  Cached revision  for
multiples of 1000, 100-patch delta  for multiples of 100, and 10-patch
delta for multiples of 10.

$ tla get ... patch-3421
* Getting cached revision 3000
* Patching for revision 3100
* Patching for revision 3200
* Patching for revision 3300
* Patching for revision 3400
* Patching for revision 3410
* Patching for revision 3420
* Patching for revision 3421

Without using too much disk  space, this could dramatically reduce the
amount of patches to download to get a revision.

-- 
Matthieu