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 _______________________________________________ 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/
