[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r11768 - trunk/subversion/tests/clients/cmdline

From: Jani Averbach <jaa_at_jaa.iki.fi>
Date: 2004-11-08 22:34:47 CET

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.