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 _______________________________________________ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list
