>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.
compilers generally understand things such as syntax and sematic errors, for which they will give you a line number and a problem diagnosis. Also you can work with colorized source code and what-not, making a missing comma or paren very blatant. with xml, if you are missing an end-tag, or youve introduced an overlapped tag, or any other of a number of minor problems you wont get as much help from dia in fixing it. I could imagine cvs working fine on a text xml, right up until a conflict happens, then youre going to lose work. In reality, dia files are essentially binary as far as cvs is concerned: they have rigid internal structure unlike a readme or a context insensitive programming language. On the other hand, html of the hand written sort works great in cvs: being written by hand and in a less exacting format (im excluding xhtml, and speaking of forgiving variants of SMGL-HTML which is what browsers generally implement) it interacts with cvs fine, and errors introduced in diffs are usually very obvious when looking at the file. (having italics bleed through your page wont crash the browser). Its a strange duality of XML: Im all for it as a programmer, but I must concede that they are not hand-editable. Therefore I would never advocate xhtml for hand-written web pages ( because a standards compliant client would refuse to display a page with any error on it) or for checking into cvs as free-form text. On the otherhand it is posible to write binary-differs, which know enough about a particular format to handle conflicts. It may be enough to have an XML differ, but that certainly wouldnt be userfriendly to someone trying to resolve a diagram conflict. I dont forsee anything like that happening soon, but if someone wants to put hooks in for tagging diagram objects as possibly conflicts vs another object in the same diagram - then adding a resolv dialog that lets you choose to keep one/both/niether that could be a long ways towards it... then for generating the diff-diagram, perhaps moving objects to other layers, (previous, new-changes) and setting them to be shown in different drawing modes (show previous in 50% opacity red, show current in 100% opacity underneath) as part of their conflict status, which would be removed once they had been resolved... or maybe the conflict attributes would be built-ins done by dia... just ideas... _______________________________________________ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list
