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

[Aaron Bentley]

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.