Re: [Gnu-arch-users] GNU Arch 2.0 -- first source

[Aaron Bentley]

Clark McGrew wrote:
> On Tue, 2005-07-12 at 10:25 -0400, Aaron Bentley wrote:
> 
> 
>>>is probably
>>>not a problem most of the time for most users, but that implies it is a
>>>problem some of the time for some users.  It seems that the current
>>>manifest format could be easily extended to allow both full file and
>>>delta changes.  
>>
>>In my opinion, don't worry about it.  Contents storage should be an
>>abstraction: request contents for id foo, receive stream for id foo.
> 
> 
> My impression is that arch intends to be the "one SCM to rule them all".
> I consider it to be a laudable goal, but it means that revc will be used
> in all sorts of crazy ways.  For instance, concerning the  current
> "whole file" vs "deltas" discussion, I know of at least one file in our
> CVS repository where the whole-file approach is optimally wrong (yes,
> the implementation is crazy) and its a difference of 35M vs a few K per
> year.  I expect somebody to jump up and says, "But, that's not a
> problem!",  but the true answer is "Work with it for now and if it
> becomes an issue there are relatively straight forward solutions."

I think you misunderstand me.  I'm not saying that we shouldn't care
about the case where whole-file is the wrong approach.  I'm saying
you're trying to solve it in the wrong place.

If we have a clean abstraction boundary between storage representation
and inventory manifest, then we can easily switch between different
storage representations, layer them, or mix and match them for different
files.  Different users can tweak for size or speed.

It would also make new formats fairly easy to implement, and this
project with the 35M of changed-contents could actually go and invent
their own if they felt none of the existing ones met their needs well.
By which I mean: you could conceivably implement storage representations
that understood the formats they were storing, and could therefore store
binaries with insane efficiency.

On the other hand, if you stick data about storage representation into
the inventory representation, you make it harder to change either one.

> I hope strategies to handle storage concerns enter into the initial
> design, at least to the extent of making sure that the internal
> "archive" format can be extended.

By all means, debate on.  I was only saying you're attacking the problem
in the wrong place, not that the problem doesn't merit descussion.

Aaron

-- 
Aaron Bentley
Director of Technology
Panometrics, Inc.