Re: planning 2.0? (was re: Google...)

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