[Gnu-arch-users] Re: File-tpye plug-in architecture for Arch?

[Tom Lord]

    > From: michael josenhans <address@hidden>

    > Tom Lord wrote:

    >> As a practical matter, the foundational problem to solve first is the
    >>  "diff/patch" problem.

    > True. This is likely the best way to go forward.

    > There is however one minor difference. OO-files are zipped directoies
    > (with subdirectories) containing XML-files.

    > I think it should be Archs job to deal with the directory and files
    > inside (adding files, deleing files, subdirectory handling, ...) I would
    > like the xml-diff/patch tools to focus soley on doing diffs to the
    > XML-files.

That seems unwise.   For example, given three copies of one of the OO
"zipped directories":

                ANCESTOR
       MINE <--'       `--> HIS

where both MINE and HIS are modified versions of ANCESTOR, and both
add or delete or rename files but in possibly conflicting ways, how is
arch to merge this and still be sure of producing a valid OO zipped
directory?   If conflicts occur, how is arch to represent those
conflicts in such a way that users can easilly resolve them?   For
that matter, how are the tags for files internal to these OO bundles
to be represented?

I don't know the OO format but _perhaps_ it sufficiently constrained
on what goes into these bundles that those questions have answers.
But then in that case, you're talking about building into arch special
treatment for a narrowly defined subset of zipped directories -- that
seems a strangely arbitrary thing to do.

On the other hand, if the OO bundles _are_ suitably constrained, then
you might be able to write an xdiff that handles them partly by 
(a) expanding them into real trees;  (b) recursively using arch's
mkpatch/dopatch tools on those trees; (c) bundling the result back up.
(No special arch hacks needed in there.)

    > E.g. adding an jpg-image to the oo-file would be a patchset
    > adding a the jpg-file to the directory and changing 2 xml-nodes
    > in 2 different files.

That description makes it sound as though the contents of the OO file
are _not_ suitably constrained.   Arch blindly treating them as if
they were ordinary directories will likely not do the right thing.

Treating these OO bundles as binary files (e.g., not attempting
merging on them; not attempting diff-based compression) may well be as
good as can be done and still have a result that OO users can cope
with.

    > I have googled around [....]

That's good.  

You may find, though, that nothing off-the-shelf is going to work
quite right here.

Here's a note to anyone who wants to, in the future, design a new
format for office documents:

        PLAN FOR AUTOMATED DOCUMENT MERGING IN YOUR EDITOR.

Make sure that:

  (a) it's easy to compute diffs on your documents

  (b) it's easy to compute 3-way merges on your documents

  (c) above all: make sure that your format
      _includes_a_way_to_represent_merge_conflicts_ and your editor
      knows how to display conflicts and help the user to resolve them

Absent that help from the editor, I think it's hard to bring revision
control concepts to office documents.  The best hope is if the
document format is sufficiently flexible that merging features can be
expressed in it even though they weren't explicitly planned for.

-t