Re: [lmi] Concinnity test for "xml files"

[Greg Chicares]

On 2006-10-31 16:44 UTC, Evgeniy Tarassov wrote:
> On 10/31/06, Greg Chicares <address@hidden> wrote:
> 
>> I see '$Id$" in 'format.xml' (I didn't check the other files).
>> I think you need "$Id $" with a space for replacement to occur.
>> I've run into that problem before, myself.
> 
> It is strange but i see a keyword being updated in format.xml. I have
> checked out a completly fresh copy of xml-gnome-branch to check that
> format.xml contains $Id $, and it is being updated. Maybe the change i
> made to the cvs substitution mode does not propagate to clients using
> that repository and everyone should check out once again these files?
> It is only an unsophisticated guess.

Let's see--online 'viewcvs' says this:
  24 :  etarassov       1.1.2.4          $Id: $
Maybe my advice to use "$Id: $" was incorrect after all?
Wendy might know: we've seen this sort of problem before,
but I thought that was the solution.

Or has the cvs substitution mode still not actually changed
for that file? In my local 'CVS/Entries' I see:
  /format.xml/1.1.2.7/Tue Oct 31 16:28:52 2006/-kk/Tgnome-xml-branch
but I'm not sure whether 'cvs' would treat '-kk' as sticky
in this case and not change my local copy when the online
repository changes, and I don't think 'viewcvs' shows what's
in the 'CVS' directory.

>> BTW, how did you ever get the substitution mode changed?
>> 'ChangeLog' says:
>>   20061030T1725Z <address@hidden> [1161]
>>   Change cvs substitution mode to default to '-kkv'. Fix RCS Id again.
>>   The previous change 20061030T1206Z did not work.
>> after I had tried repeatedly, without much success. I'd like
>> to learn the right way to do this.
> 
> I'm using the Eclipse platform to work with lmi cvs repository. And it
> hides all the cvs related tasks behind a gui. Do you want me to check
> in a dummy text file (cvs_substitution_mode_test) into lmi's
> repository, change its substitution mode using Eclipse and save the
> cvs log?

I had assumed that you were issuing 'cvs' commands directly,
and knew some secret that has eluded me. But if 'eclipse'
lets you see the actual 'cvs' commands, then this idea sounds
worthwhile. It can however be deferred if it's not trivial;
I'll make sure I pay careful attention to the substitution
mode when merging into HEAD, and then the problem will stop.

>> > However there is still one hidden problem with common.xsl and
>> > tab_delimited.xsl which is not resolved. These files are used to
>> > produce TSV and any extra-space or an unwanted-LF could break the
>> > output. Both files were formatted in a way to exclude any possibility
>> > of such a additional space or LF, but after xmllin reformatted the
>> > files it is unreadable.
>>
>> It's painful to think that a 'lint' tool would perform a damaging
>> transformation, but we can't easily fix the tool ourselves.
> 
> My guess is that this transformation should not damage nothing at all
> if the xsl template is properly written, so for me its a problem in
> our xsl templates and not in the xmllint.
> 
>> > It should not hold back calculation summary testing because the
>> > template as it is now should work as intended. Only the readability
>> > suffers.
>>
>> If 'xmllint' really just makes '.xsl' files worse, then I guess
>> we should just write them the way we want, for readability, and
>> exempt them from the 'xmllint' test. Is there no option for
>> 'xmllint' to make it accept what we want to do, though? It has
>> dozens of options, and I've never tried to understand them.
>> Or, if that doesn't work, and the things 'xmllint' dislikes
>> are limited in scope, we can filter them out of the 'diff'
>> comparison, so that 'make check_concinnity' will ignore them.
> 
> Do you think i could change xsl template later so that they look
> pretty? It should not be that much of changes to apply -- more of
> studying how exactly xsl works with spaces and some testing.

Sure, later.

> I dislike the way common.xsl and tab_delimited.xsl are written -- it
> something similar to what they do with html files to workaround an
> unwanted feature of internet explorer for an html document being
> rendered in 'Quirks mode'. The html code that should be written like:
> <ul>
>  <li>item</li>
>  <li>item 2</li>
> </ul>
> gets some extra spaces after rendering and they used to code it like:
> <ul
>  ><li>item</li
>  ><il>item2</li
>> </ul>
> 
> Which is exactly what is used in common.xsl and tab_delimited.xsl atm.
> 
> If you dont mind i would prefer to fix the files (a little bit later),
> instead of modifying makefiles.

Okay. Maybe the new version of 'explorer' fixes that? Just a
wild guess: I don't use the thing.