[Top][All Lists]

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

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

From: Thomas Zander
Subject: [Gnu-arch-users] Re: revision control for documents (was plug-in foo)
Date: Tue, 23 Dec 2003 10:57:39 +0100
User-agent: KMail/1.5.94

Hash: SHA1

On Monday 22 December 2003 19:22, Tom Lord wrote:
>     > 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.
> I have little idea what you might be talking about.  "widget"?  "DOM
> domain objects"?  

I'll explain that little parag to you. Sorry for not talking the time to 
simplify things..

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.
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.
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.
Normal paragraph rewrites are nothing but ok/discard, but merge conflicts 
which happen because 2 independent sources added a paragraph at a specific 
place are handled differently.
The user will have to choose not only if, and which change to use; but also 
the ordering (which comes before the other) of the new paragraphs.

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.
- -- 
Thomas Zander
Version: GnuPG v1.2.3 (GNU/Linux)


reply via email to

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