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

[Thomas Zander]

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

On Sunday 21 December 2003 17:57, Tom Lord wrote:
>     > From: michael josenhans <address@hidden>
>     > In XML the following terms are devared as equivalent:
>     >
>     > a) <nodename attiribute='5656'></nodename>
>     > b) <nodename attiribute='5656'/>
>     >
>     > Spaces outside the nodes are irrelevant. Thus according to
>     > standard after reading and saving a XML-file, the XML-file might
>     > look different, even if its content has not changed.
>
> Yikes.
>
> On the one hand, sure, you could abstract the `cmp' and conceptually
> the world doesn't fall apart.
>
> But on the other hand, that would mean (for example) that `get' would
> sometimes return a tree whose source files are not byte-wise
> equivalent to those that were passed to `commit'.   It's a pretty
> big leap of faith to think that that's desirable.

If a file is an honest XML file I fail to see why this would be a problem;
remember that the whole idea of using an xmlDiff on the file was to avoid
merge conflicts since
   <bla name1="val" name2=val" />
and
   <bla name2="val" name1=val" />
give a change in diff(1) but are really equivalent (as just another example)

It all revolves around what you conceptual level the diff works on.
Or in other words; a get after a commit would always return the same content.
Although a file-compare would not agree. This is nothing but a slight
adjustment of your definition.

>     >> b) Can you do inexact patching?
>     >
>     > The tool (http://www.cs.wisc.edu/~yuanwang/xdiff.html) claims to
>     > achieve this by using hashes on XML nodes.
>     >
>     > Alternatively, if we would havel the file format under control, we
>     > could tag the XML nodes.
>
> I'm not at all convinced that generic XML-diff/patch tools are what
> you ought to be looking at.   They only make sense if, either
> deliberately or by accident, the document formats are robust and
> meaningful under the transformations of a generic XML-diff/patch.

That is the whole point of such diffing tools and XML in general. So you can
assume they are [robust].

> I think it unlikely that the document formats were designed with any
> XML-diff/patch algorithm in mind.   I think it implausible that they
> will be robust under those transforms "by accident".

Then you have not read the XML specs which says otherwise.  In short an XML
will be plainly rejected (and not parsed at all) if the formatting is
incorrect.  This is a good thing.  As someone who wrote the file format for
KOffice, please take my word for it that this is no problem if you are
talking about real XML files.

>     > Would be modifications to arch needed to enable working with
>     > compressed files?
>
> I doubt such modifications would really help you.  They are unlikely
> to be seriously considered for arch.

Well; are there options to take a different 'diff' application for a different
filetype?  If so then the problem would be solved outside of arch, which
would make everyone happy.

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

iD8DBQE/5uvcCojCW6H2z/QRAtOcAJ9LNxlGy4mT6qXYYpQ3qpIZaZcTkQCgwVWs
CybxAC86QX6VyOy8NNHNUYM=
=VL+Y
-----END PGP SIGNATURE-----