On 2004-11-08 10:15-0600, kfogel@collab.net wrote:
> Jani Averbach <jaa@jaa.iki.fi> writes:
> > > This was a bit surprising to me... Why wouldn't one open a text base
> > > file as binary in every case? What bad effect was it having?
> >
> > I have the 'to be expected' keyword strings and keyword stubs written
> > as: '$URL:: ..... \n' and python writes them to the disk with "\r\n"
> > line endings on Windows. If I read those strings back to python on
> > text mode, the line ends are exactly '\n' (which will match my test
> > strings). If I read them as binary (rb), the string will contain
> > "\r\n" which won't match with '\n' (extra '\r'). The
> > fixed_keyword_test file doesn't use svn:eol-style=native, so the text
> > base is indeed in '\r\n' mode.
> >
> > It is fun, isn't it?
>
> Eeuww, yes :-).
>
> So it would be better if could have the strings in the source code
> contain the correct line endings, the ones that will be written to out
> the text-bases, so that reading the text-base in binary mode results
> in the correct strings... But I'm not sure how to do that.
Ok, I think we could use 'os.linesep' [1] for constructing the test
strings, and open all files in binary mode. But then we need a new
binary version of svn.append_file, and at the end we will be doing the
same thing what Python is doing for us at the moment. So is it worth
of it? If we like to write a test case where we mix keyword
expansions and line-endings, then yes, but for the _current_ test case
it should not bring any extra value.
Br, Jani
1) http://www.python.org/doc/2.3.4/lib/os-path.html
--
Jani Averbach
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 8 22:35:27 2004