svn_client_blame2 was reported to be broken with 'native' eol style on
Windows. This happens to be our only platform to need translation
from the normal form to have its eols fixed, so, if something is wrong
wrt eols, it's detected there.
The problem however is a bit bigger than I expected. In r17514 and
r17536 I commetted what I thought were fixes for issue #2431. Though
they happen to resolve the symptom, I'll need to change a lot to call
it an actual fix, because in the process, I broke multi-rev blames
(which is kind of the point of blame, isn't it :-).
So, what's wrong? Well, currently, trunk translates the file from
normal form into the right eols and then calculates the blame. So far
so good. On the next iteration however, it takes this detranslated
file and applies the svndiff to it which it should have applied to the
normal form. BAD.
Not as bad as I expected, because the file is being read on a
line-by-line basis in svn_client_blame, after the blame data has been
collected. Currently, this is done with a default "\n" line ending,
but r17514 added code to find out about the requested eol_str eol
style, so, if I translate the file to that line ending (on the fly, by
using the translating stream) and then read from it with the correct
line ending, the line endings issue should be solved.
Well, it's not: if I read from the stream (using svn_stream_readline),
the eol marker isn't part of the returned string. This means I need a
way to marshall it to the client. Creating a new blame receiver
callback to do that would require revving the blame receiver *and*
svn_client_blame2. Creating svn_client_blame3 and adding a parameter
to tell it to either in- or exclude the line ending would eliminate
the need to rev the blame receiver as well.
In libsvn_client/blame.c this will all get quite messy, since the
current code passes CR's to the blame receiver, even if it's part of
the eol marker. This behaviour should probably be kept for backward
compatibility, but the new code should eat the eol all the way :-)
So, to cut a long story short: I'll be creating svn_client_blame3,
which takes the same blame callback, but possibly includes eols in the
when returned line value. When a callback is passed to
svn_client_blame2, it keeps its current behaviour of
not-eating-CR's-but-eating-LFs.
Comments?
bye,
Erik.
Received on Mon Dec 5 22:40:39 2005