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