[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnu-arch-users] arch 2.0 and delta compression
From: |
Thomas Lord |
Subject: |
[Gnu-arch-users] arch 2.0 and delta compression |
Date: |
Tue, 12 Jul 2005 11:12:14 -0700 |
On Tue, 2005-07-12 at 10:25 -0400, Aaron Bentley wrote:
> It should be possible to add additional storage formats based on
weaves,
> or tarred patches, or rot13 encoding at a later date.
If people want the *space efficiency* of delta-compression
they are being over-picky: *any* kind of compression that
works across the boundaries of individual files will do.
It's interesting that you site a second reason to want
not only delta-compression but weaves specifically:
> Martin's using weaves not so much for the space improvements as for
the
> fast access to annotation data, because annotation-based merges (like
> Codeville's) have some significant advantages over three-way merges.
I'm very skeptical of "the Codeville merge algorithm" for reasons
not terribly important here. Let's stipulate, for the sake
of conversation, that it's the greatest thing since toast and,
additionally, that it imposes a moral imperative on revctl developers
to optimize-for-annotate.
Piece of cake. If people are serious, we can perhaps make this
a 9-month goal for revc 2.5.
The difficulty, and why I'm not leaping to the cause on this one
at just this moment, is that optimize-for-annotate complicates
storage management by -- guessing -- 3x lines of code. I.e., I
have maybe a few hundred lines for reading and writing blobs --
that would grow to a couple of thousand. And trickier code, too.
Since I'm skeptical anything is actually gained, I've got higher
priorities but if you think it through, it's actually quite
easy (just tedious).
-t
- [Gnu-arch-users] arch 2.0 and delta compression,
Thomas Lord <=