You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Kouhei Sutou <ko...@cozmixng.org> on 2007/02/09 13:01:52 UTC
EOL handling policy on the Ruby bindings
Hi Joe,
Sorry for my late response. Here are my new idea for handing
EOL:
* Don't modify a result of Subversion. Subversion uses
system EOL if EOL is needed and this doesn't have any
relationship with file's EOL. So, I think that we
shouldn't normalize EOL of a result to "\r\n" or "\n".
(e.g. svn_diff_file_output_unified2() uses "\r\n" on
Windows for header:
--- XXX.old\r\n
+++ XXX.new\r\n
...
But it uses "\n" on Linux and so on:
--- XXX.old\n
+++ XXX.new\n
...
)
* Use "\n" in a sample source for testing.
* Don't use binary mode for writing and/or reading from/to
file in tests except translated_file related methods
tests.
* 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
Am I still stupid...?
Thanks,
--
kou
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: EOL handling policy on the Ruby bindings
Posted by Kouhei Sutou <ko...@cozmixng.org>.
Hi Joe,
I'm sorry for my late response...
In <ae...@mail.gmail.com>
"Re: EOL handling policy on the Ruby bindings" on Sun, 25 Feb 2007 09:45:21 -0800,
"Joe Swatosh" <jo...@gmail.com> wrote:
> > # It's better that I make a build system on Windows but it's
> > # difficult for me...
>
> If I can assist you if you decide to try to make a windows build
> system, please contact me offline.
I'm trying to build on Windows. Please wait a week.
Thanks,
--
kou
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: EOL handling policy on the Ruby bindings
Posted by Joe Swatosh <jo...@gmail.com>.
Hi kou,
On 2/16/07, Kouhei Sutou <ko...@cozmixng.org> wrote:
> Hi Joe,
>
> I'm so sorry for my late response again...
No problem. I'm on the way to a family weekend at the beach so I
don't have time to really reply. I'll reply for real on Monday or
Tuesday (my time, I think you're 19 hours ahead of me...).
--
Joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: EOL handling policy on the Ruby bindings
Posted by Joe Swatosh <jo...@gmail.com>.
Hi kou,
I'm sorry this took me much longer to get to than I had anticipated.
On 2/16/07, Kouhei Sutou <ko...@cozmixng.org> wrote:
> Hi Joe,
>
> I'm so sorry for my late response again...
>
> In <ae...@mail.gmail.com>
> "Re: EOL handling policy on the Ruby bindings" on Sun, 11 Feb 2007 14:45:25 -0800,
> "Joe Swatosh" <jo...@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
Re: EOL handling policy on the Ruby bindings
Posted by Kouhei Sutou <ko...@cozmixng.org>.
Hi Joe,
I'm so sorry for my late response again...
In <ae...@mail.gmail.com>
"Re: EOL handling policy on the Ruby bindings" on Sun, 11 Feb 2007 14:45:25 -0800,
"Joe Swatosh" <jo...@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).
> > * 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.
> > * 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.
# It's better that I make a build system on Windows but it's
# difficult for me...
Thanks,
--
kou
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org