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

[Lars Clausen <lrclause cs uiuc edu>]

On Mon, 29 Apr 2002, rob campbell wrote:
> 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.

Dia prints the XML rather prettily:

...
  <dia:layer name="Background" visible="true">
    <dia:object type="SADT - arrow" version="0" id="O0">
      <dia:attribute name="obj_pos">
        <dia:point val="25,-8.5"/>
      </dia:attribute>
...

> 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 believe the ordering in the file is defined by the ordering in the layer,
so it's somewhat stable.

There is an xmldiff, it may or may not be possible to hack CVS to use
that.  Haven't tried it.

-Lars

-- 
Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| Hårdgrim of Numenor
"I do not agree with a word that you say, but I   |----------------------------
will defend to the death your right to say it."   | Where are we going, and
    --Evelyn Beatrice Hall paraphrasing Voltaire  | what's with the handbasket?