Re: [Gnu-arch-users] Re: revision control for documents (was plug-in foo)

[Tom Lord]

   >>>= Thomas Zander

   >>> Besides; the proposal was to make the merge-conflicts be
   >>> handled by OOo in a specific 'merge' widget that converts the
   >>> DOM domain objects to viewable changes so the user can select
   >>> the revision (A, B, A and B, B and A) that should be used in
   >>> the resulting document.

   >>= Tom Lord
   >> I have little idea what you might be talking about. "widget"? "DOM
   >> domain objects"?

   >= Thomas Zander <address@hidden>

   > The idea was never to have a 100% automatic merge tool; people
   > don't even want that. If a paragraph was re-written by someone
   > else the original author will probably want to see that before he
   > ok's it.

That much we agree on.

   > If user 1 added a paragraph and user 2 added a paragraph at the
   > same position; you _will_ have a merge error. No matter how good
   > your software. Plus that this is actually what you want.

Minor quibble: I don't know that you'd want to describe that as a
"merge error" but yes, _all_ changes introduced by a merge to a
document, including two users putting paragraphs in roughly the same
place, should (at least usually) be marked up for the user doing the
merge to review.


   > So (to start explaining the above parag); the proposal was to
   > make a graphics component (aka Widget) so the user can see the
   > changes, probably one by one and Ok/discard them.

There's quite a bit hidden behind that statement.

First, there's the presumption that this "widget" is in some way
distinct from the usual editor for this document type.   That strikes
me as nothing but an annoyance for users.   The capabilities of the
editor are at least already _close_ to being able to serve as a merge
tool -- so if one is going to hack, why not hack the editor rather
than building a separate "widget"?

Second, there's a strong suggestion here that the output of the
(batch) merge tool is not a document of the same type as the inputs --
but is instead a document of the type understood by this widget.  In
other words:

        [OO doc] 
           |
        (merge stuff in)
           |
           V
        [merge report]
           |
         (use the merge widget)
           |
           V
        [OO doc]

That indirection seems undesirable to me.   I'd rather see some effort
at avoiding it.

   > Going from a xml-diff to an on-screen display is a 3 step
   > process; after the xml-diff is produced it is converted to a
   > DocumentObjectModel in-memory tree that is 'attached' to the
   > original tree. In effect its an in-memory representation of the
   > diff.  Notice that this tree of objects is anonymous; its just
   > XML nodes (called Elements). No application-level data is used to
   > create this.

   > Next there will have to be code that converts from XML Elements
   > to application-data structures.  Luckily many objects have a
   > constructor (since its C++ its object oriented) which take an XML
   > Element.

   > After merging a new DOM is delivered by the merging widget and
   > written to disk, or opened as a new document.

   > Hope that explains the idea.

I don't see any solution to the problem there -- just a vague mention
of various technologies you'd like to use to try to solve the problem.

Let's say that you xml-diff a pair of content.xml components from some
documents.   Now, indeed, you can build a data structure that relates
the elements of the diff to the elements of the orginal documents.

But as you point out, no application-data is used for that.  Which
means that the xml-diff is not contrained to produce a description of
the changes which has anything whatsoever to do with the conceptual
model of the document that the application user has.   It's likely,
even, that the diff is going to describe some changes that simply
reflect the way the deep dark internals of the document's XML
representation has changed -- a user who is not intimately familiar
with the XML representation of OpenOffice documents won't be able to
make heads or tails of this.

What you're saying, behind all the buzzwords, is that, perhaps with a
little bit of GUI help, your solution to the merge problem is to help
the users to massage the raw XML of the document representation.  By
coincidence in some cases, yes, the user will see "oh, ok, a paragraph
was added here" but in other cases, you're going to wind up with users
puzzling out what it means that a merge has changed the
style:master-page-name property of a style:style element.

You're just dancing around the problem and handwaving about your
favorite technologies -- not actually solving it.

-t