Re: [Gnu-arch-users] planning 2.0? (was re: Google...)

[Thomas Lord]

Peter> I don't think an RCS should have any special knowledge about
Peter> specific applications. An RCS as such should be able to handle
Peter> office stuff or wikis or whatever as binary or maybe plain text
Peter> files, nothing more.  Keep It Small & Simple.

Peter> An RCS *should* be extendable in a way that made it better at
Peter> handling specific file formats, e. g. by making the diff and
Peter> merge algorithms exchangable.

I agree that an RCS should be simple, have a small core, and have a
modular and extensible architecture.

It does not follow from that that an RCS should always treat files
with non-line-oriented formats as plain text or binary files.  That
might be a good fallback but it isn't desirable in the general case.

Two issues come to mind:

1. delta compression

 If and when an RCS makes use of delta compression for storage,
 for some media types, media-specific delta computation is
 desirable.


2. delta signing and archiving

 One of the roles of an RCS is to archive commits along with
 authentication information:  signed commits.

 It is useful for users to be able to sign complete revisions,
 asserting "This is the whole tree I am committing."

 It is *also* useful for users to be able to sign applicable
 deltas, asserting "This accurately describes the changes I
 am making."


-t