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

["Maiorana, Jason" <jmaiorana idirect 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.

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...