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

[Thomas Zander]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 21 December 2003 15:11, you wrote:
> Thomas Zander wrote:
> > In KOffice and on OpenOffice there have been on-and-off discussions on
> > saving the file to a filesystem layer like 'cvs://'.
> > This touches the same idea, and sidesteppes some problems your solution
> > will face.
>
> My idea would be to make tools like OO patchset-aware. The current way
> of change tracking does not work according my understanding very well.
>
> This is not an OO-problem, but rather a revision mangement problems all
> office suites face that I know.

Do note that the OOo fileformat (from the link I provided in my other mail) is
going to be used by all office suites in the near future; so GUIs and all
have to be portable, the rest can just be re-used.

> > Since OOo will save some 5 different XML streams inside a zip file its
> > quite easy to do revision management on XML only streams once you have a
> > XMLDiff application in place. (which should be first priority)
>
> It is actually my motiavtion. Even an OO-change tracking mode could be
> implemented starting the initial files. When changes are added, patches
> could be stored as patchsets by OO in the OO-zip file container
> invisible to the user, maybe in a different revision history directory.
>
> This would enable revison tracking for the sake of loading speed and
> eventually branching for the sake of loading / saving speed.
>
> When change tracking is disabled, all patchset could be merged
> immediately when saving.

Right.

>  > Simply because they need to what the changes
> > mean on screen. That part will be done in the office suites and can be
> > done with the current tla interface.
>
> I would not like to merge a spreadsheet table with a diff tool, which
> does not know what a cell, a color or a formula is. Only geeks would
> like to that.

If you are thinking of merging (the thought had not even crossed my mind) I
assume you mean something like opening a document in OOo and opening a second
with a command called 'merge'. OOo could then show all the changes in the
merge document and let you Ok them one by one.  Merging conflicts like the
one you point out below (with the XML) could be solved with an XMLDIff
application I pointed out before. (freshmeat: xmldiff)

Would be cool ;)

> I agree here. But first we should understand patching of XML files and
> their limitations.

You are thinking far too much in the diff(1) manner, which diff3(1) does not
really make a change in.
I'm Pretty sure an XML like this:
   <bla name1="val" name2=val" />
changed into:
   <bla name2="val" name1=val" />
will _not_ produce a change in XMLDiff, if it does then it needs more work.
In the same context; changes like one variable value (name for example) will
be minimal changes and your diffing tool could be educated to ignore such
things.

I suggest to try out the XMLDiff tools available and see how much they help.
...
> As a first goal I would see, making arch xml aware and eventually able
> to work with zipped directories.
Sounds cool; I would like to see that work.

- --
Thomas Zander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/5uZzCojCW6H2z/QRAnxbAKDi6qxcQx7y2Dm/DK8rsuzX4/7bpACg79tu
p5em2VQ/6k+njSe0fMcOLbk=
=PqJL
-----END PGP SIGNATURE-----