Erik Huelsmann wrote:
> 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 :-).
[...]
> 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 :-)
That behaviour should perhaps be kept for svn_client_blame2() for backward
compatibility, though if it's not documented we can call it a bug and fix it.
That behaviour certainly does not need to be kept as an option in
svn_client_blame3().
> 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.
From an API point of view, that sounds too messy. Just pick a good interface
(either one that returns the EOLs, or one that doesn't) and stick with it. I
don't see the need for a run-time option.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 7 11:32:25 2005