RE: CVS and uncompressed Dia files? (RE: Is there a more stable version than 0.88.1?)

[rob campbell att net]

Diff doesn't actually know anything about the semantics
of the language, though, right?  Which is why CVS works
seamlessly with C, Pascal, or readme files.  I think it
is line oriented.  The only thing it cares about when
merging two changes derived from the same revision of a
file is their proximity in terms of the number of lines.
 If they are too close, it "spooks" the diff and the
second commit is refused.

I don't about the way Dia writes its XML.  Since it isn't
intended to be processed by a human, I don't expect it
makes much use of line breaks and other "pretty
printing".  Maybe if it did, CVS would be able to process
it more efficiently and create smaller diffs.  This is
what I was thinking of by changes that would make Dia
play nice with CVS.

Another would be to ensure that objects are always
written out in the same order.  It would be a problem if
a particular user option had the side effect of chaning
this behavior.  It would also be a problem if, when an
existing object is modified, its position in the write
order is moved to the end.

I don't know if things work the way I've described; I'm
just speculating.  And I'm certainly not requesting this
functionality.

Rob