[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

-----BEGIN PGP SIGNED MESSAGE-----
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/6BGTCojCW6H2z/QRAs0mAKCyYhL9Ux7M9HEEEYtiTklRtwJBDACgh9fS
xApVG5zG+Xbl9IJvTq0TPfE=
=7MJj
-----END PGP SIGNATURE-----