Clark McGrew wrote: > I agree with others that saving full files in a change set
AIUI, this is not about changesets, but about the way files are stored for revisions. Arch 1 used changesets to represent revisions, but I think Arch 2 doesn't. > 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. (Your IDs are SHA-1 sums in Arch and git. Other VCSes may use other ids.) Only the storage implementation should have to worry about the pysical representation of the contents. It should be possible to add additional storage formats based on weaves, or tarred patches, or rot13 encoding at a later date. Bazaar-NG (bzr) currently uses a git-like gzipped-full-contents store, but Martin's currently adding weave support. When he's done, you'll be able to branch from a weave-based tree into a full-contents tree and back again. The same approach could be taken with Arch 2, if people really want a more-compressed form. People want fast access to recent revisions, but will probably accept slower access to older revisions, so you could have a full-contents cache (with auto expiry, please!) in front of a weave/revfile/sccs/rcs/dns/series-of-patches store. 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. 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/
