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 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. Then topics like the current "whole-file" vs "delta-compression", or even "SHA1" vs "your hash here" discussions are answered with, "The archive format has been designed to allow for extensions. If <fill-in-the-blank> is a problem we have a clear solution available. Please submit a patch." -Clark -- Clark McGrew Univ. at Stony Brook, Physics and Astronomy <[EMAIL PROTECTED]> 631-632-8299 _______________________________________________ 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/
