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

[michael josenhans]

Tom Lord wrote:
>                 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?

If you want to merge files created by different people the current 
xml-diff and xml-patch tools are insufficient.

These tools would not be able to cope with any addional branch (no his 
would be possible.)

        
Any useful xml-diff tool must either be able to remember node changes 
applied by patches is the past or must use some explicit tagging.

Here is some example (non-OO) XML code using node taging:


both mine.xml and his.xml have inherited the Introduction-part from a 
common branch0. Mine has also added and image, while his has added the 
main part.

mine.xml:

<text-node
        tagID= "branch0-000001"
        style="Headline" >Introduction
</text-node>
<text-node
        tagID= "branch0-000001"
        style="Standard" > This is the text to Introduction
</text-node>
<image-node tagID= "branch1-000001" image="bluescreen.jpeg"/>

his.xml:

<text-node
        tagID= "branch0-000001"
        style="Headline" >Introduction
</text-node>
<text-node
        tagID= "branch0-000001"
        style="Standard" > This is the text to Introduction
</text-node>
<text-node
        tagID= "branch2-000001"
        style="Headline">Main
</text-node>
<text-node
        tagID= "branch2-000002"
        style="Standard">This is the text to Main
</text-node>

By comparing the tags, it should be possible to merge the files. However 
it is not clear, whether the image shall be merged after the main part 
or stay after the introduction. Thus the tags (tag_ID) may help find the 
place where to put the nodes, when merging files, however it still might 
be ambigous. (Note that OO-has no tagID's to mark the nodes.)

> 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.)

Do I understand you right. Is a XML-tree to file-inode-tree converter 
you are talking about? This would create an Inode for each XML-node?

After merging is done, everything is converted back to XML?

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

One file is like above. The other file is just a an xml-node with list 
of files in the oo-files. The latter would likely not be a problem, in 
the first the tool could suggest the user 2 places.
>     > 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.

Agree.

Michael