Re: EOL handling policy on the Ruby bindings

Hi kou,

I'm sorry this took me much longer to get to than I had anticipated.

On 2/16/07, Kouhei Sutou <kou@cozmixng.org> wrote:
> Hi Joe,
>
> I'm so sorry for my late response again...
>
> In <ae6cb1100702111445h1e90805fte9d7c357d46fea86@mail.gmail.com>
> "Re: EOL handling policy on the Ruby bindings" on Sun, 11 Feb 2007 14:45:25 -0800,
> "Joe Swatosh" <joe.swatosh@gmail.com> wrote:
>
> > subversion repository. I'm not completely certain when we are
> > providing information _about_ the data being stored in the repository,
> > that we shouldn't report it in a "ruby standard" way. Now whether or
> > not diff is data from the repo, or data about the repo is another
> > question.
>
> Hmm... Could you give us a example what you worry about?
> What is the information about the data? EOL style of a file?
> If so, we already provide the way: propget("svn:eol-style",
> file_name).
>

What I was thinking is that the file itself was being stored in the
repository (what I was referring to as being "in the repository") and
the differences between two versions of the file in the repository
(this was an example of what I was thinking of as information about
the data in the repo). I think now that I came to this by looking at
the differences test failures I was getting. I no longer think this
is reasonable.

Now, I think you are right. The differences that are causing the test
failures on windows are (mostly) whether or not we are interacting
with Subversion from Ruby through the file system or not. Basically,
where we create and write a file, then let Subversion modify it, and
we read it everything works okay. But when we get the data directly
from Subversion (maybe Svn::Core::Diff#file_diff#unified or cat
directly to a stream) is when we have the comparison failures. I
further think you're right about not modifying the data from
Subversion (as I suggested some time ago).

>
> > > * Don't use binary mode for writing and/or reading from/to
> > > file in tests except translated_file related methods
> > > tests.
> >
> > Okay. Although from the first paragraph it would seem more consistent
> > to use binary mode every where in the tests when reading or writing
> > files. Near as I can tell, all binary means in ruby is that the line
> > ending translation is suppressed. If we changed all the file reads
> > and writes to binary in the tests we wouldn't need any sort of line
> > normalization.
> >
> > I'm not really advocating using binary mode everywhere, but it seems
> > to me it might be a reasonable choice if we want to avoid these
> > issues.
>
> I think we should write tests to actively find bugs and
> should not change tests to pass easily. I think Rubyists on
> Windows normally use test mode to read/write from/to
> files. So, we should use test mode in tests.

I am not advocating this change to make it easier to pass the tests.
I was thinking of stressing the "pass-through" nature of Subversion
and the bindings. Clearly, you are correct about how Rubyists on
Windows would normally use files. If you think it is better to have a
translation function that's okay with me. It is hard for me to
anticipate all the uses these bindings might be used for. My planned
uses are fairly simple, so since I probably won't be using these APIs
myself, I'm not going to argue one way or the other.

Although, I will suggest that if you think these will be often used
functions, that it might be a valuable service that the bindings
themselves could provide to help with converting "system" line breaks
to "ruby" line breaks.

>
> > > * Convert "\n" in a sample source to system EOL for
> > > generating expected result from Subversion if it's
> > > needed. So, I want to use normalize_line_break like
> > > method:
> > >
> > > def to_system_eol(str)
> > > temp = Tempfile("ruby-svn")
> > > temp.print(str)
> > > temp.rewind
> > > temp.binmode
> > > temp.read
> > > end
> >
> > I don't see any particular advantage to using the file system to
> > convert the line endings over the existing normalize_line_break
> > method.
>
> What we want to do by normalize_line_break method is
> converting "\n" to the EOL character on the system. I think
> this implementation will describe this reason rather than
> current normalize_line_break implementation.

I think a comment would work for that. Especially if you decide that
it would be reasonable for the bindings themselves would provide a
helper function.

>
>
> # It's better that I make a build system on Windows but it's
> # difficult for me...
>
> Thanks,
> --
> kou
>

If I can assist you if you decide to try to make a windows build
system, please contact me offline.

Thanks,

--
Joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org