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 mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
