Type-specific diff & patch

Hi,

Matteo Settenvini <[email protected]> writes:

>      b) a plugin system; maybe Arch 2 should become little more than a
> specification and a framework, in the sense that gstreamer is; there
> could be plugins for a pletora of things, ranging from merging
> algorithms to supported media / transport protocols; and maybe even a
> plugin for special treatment of certain mime-types -- for example,
> imagine a .odt OpenOffice.org document: it's mostly a bunch of XML files
> compressed in a unique archive. Instead of doing a binary diff of it,
> knowing its ``semantic'' we could diff just its plain-text contents

File-specific diff would be feasible in Arch 1, and it'd be nice to do
it (I meant to give it a try but haven't had time so far).

Basically, just like we have "id tagging methods", we could have "file
diff-ing methods".  There could be a per-tree default method, as well as
per-file methods (i.e., not all files within a tree need to use a single
diff method).

Obviously, the main issue would be portability of the diff methods
used.  Each diff method would have to be named and described.  Such
meta-data could go, for instance, in the `{arch}' sub-directory of a
tree:

   {arch}
     |
     +-- =diff-methods
           |
           +-- line-oriented
           |     |
           |     +-- diff
           |     +-- diff3
           |     `-- patch
           +-- token-replacement
           |     |
           |     +-- diff
           |     `-- patch
           `-- xml
                 |
                 +-- diff
                 `-- patch


The files `diff', `diff3' and `patch' would describe command-lines to be
used to perform the corresponding operations for the diff method at
hand.

In order to allow parties interested in a branch to actually be able to
retrieve it, we would need a way to advertise the set of diff methods in
use within a branch (this would require a slight archive format change).
In practice, one had better publish not only the diff method name (e.g.,
`xml') but also a string associated with it that describes the tools to
be used (e.g., "XyDiff 0.3, see http://...").

This kind of feature would be nice, but it is unclear how much could be
gained from this.  Perhaps this is also related to the so-called "target
market" question (e.g., "Do we care about OpenOffice.org documents?").
I recently read that this kind of thing could be done quite easily in
Darcs [0], which might be another source of motivation for some people.
;-)

Thanks,
Ludovic.


[0] "Towards XML Version Control of Office Documents",
    http://www2-data.informatik.unibw-muenchen.de/People/borghoff/pspapers/doceng2005.pdf .