[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: michael josenhans
Subject: [Gnu-arch-users] Re: File-tpye plug-in architecture for Arch?
Date: Mon, 22 Dec 2003 01:20:54 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016

Tom Lord wrote:

       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.


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


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

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:


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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]