[gs-devel] Re: [gs-cvs] rev 7923 - in branches: . etc

[SaGS]

----- Original Message ----- 
From: "Till Kamppeter" <till.kamppeter at gmail.com>
To: "gs-devel" <gs-devel at ghostscript.com>
Cc: "SaGS" <sags5495 at hotmail.com>
Sent: Wednesday, 09 May 2007 11:30
Subject: Re: [gs-devel] Re: [gs-cvs] rev 7923 - in branches: . etc


> Looks like subversion recognizes this as an ID and messes it up. 
> doc/gsdoc.el was never touched by the patches of the merger.
>
> Probably all files which got explicitly listed as modified on the check-in 
> of the new branch
>
>    branches/gs-esp-gpl-merger/doc/gsdoc.el

This indeed needs a fix. And there are a few others too.

>    branches/gs-esp-gpl-merger/jbig2dec/configure.ac
>    branches/gs-esp-gpl-merger/lib/jobseparator.ps
>    branches/gs-esp-gpl-merger/src/md5.c
>    branches/gs-esp-gpl-merger/src/md5.h
>    branches/gs-esp-gpl-merger/toolbin/gen_ldf_jb2.py

These have expanded keywords (or parts of the expansion, like extra 
<colon><space>) in the "text-base". It could have been the repository 
conversion from CVS, it could come from an initial commit without the option 
to expand keywods (IIRC "jobseparator.ps" did not exist in CVS), don't know. 
It looks SVN shows them as modified if the date/time of the working copy is 
changed relative to what is recorded in ".svn\entries"; I have noticed this 
after a "svn checkout" to a NTFS volume then copying to a FAT32 one. If the 
date/time does not change, I think SVN does not actually look at the 
contents and does not flag them (it makes sense, as an optimization).

>
> need to be checked for messed $Id...$ expressions. How can one protect 
> them?

For the problems I found, there is a patch attached to the bug report I 
mentioned.

>
>    Till