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. _______________________________________________ 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/
