I should explicitly use --lf on CVS client...
Here's few interesting lines of "od -t x1 site_printable.vsl":
0000140 2e 64 74 64 22 3e 0d 0d 0a 0d 0d 0a 3c 21 2d 2d
0000160 20 43 6f 6e 74 65 6e 74 20 53 74 79 6c 65 73 68
0000200 65 65 74 20 66 6f 72 20 53 69 74 65 20 2d 2d 3e
0000220 0d 0d 0a 0d 0d 0a 20 20 20 20 23 23 20 44 65 66
You can note the strange "0d 0d 0a" sequences in it.
The file looks like this when I retrieve it with
cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic checkout
jakarta-site2/xdocs/stylesheets/site_printable.vsl
command with Windows CVS client, which by default uses --crlf.
Using explicit --lf option solved the problem...
However, I'm still puzzled: why does CVS download some files correctly even
without explicit --lf (i.e. site.vsl had no extra 0d bytes in it) and some
not?
Attila.
----- Original Message -----
From: "Jon Stevens" <[EMAIL PROTECTED]>
To: "velocity-dev" <[EMAIL PROTECTED]>
Sent: Thursday, August 23, 2001 6:36 PM
Subject: Re: Updated site.vsl and site_printable.vsl
> on 8/23/01 2:16 AM, "Attila Szegedi" <[EMAIL PROTECTED]> wrote:
>
> One more thing:
>
> It seems that site.vsl has Unix line feeds and that site_printable.vsl has
> DOS line feeds. Your patch for site.vsl was fine, your patch for the
> site_printable.vsl had extra line feeds in it and was not fine.
>
> Having DOS or Unix as the linefeeds is acceptable and most decent text
> editors can deal with it properly.
>
> I hope that helps you deduce your problems with generating patches in the
> future.
>
> thanks,
>
> -jon
>
>
