On 12/7/05, Julian Foad <julianfoad@btopenworld.com> wrote:
> 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().
Exactly my thoughts.
> > 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.
Well, then we need an interface which marshalls the EOL style to the
blame callback, because in the XML output you *don't* want EOLs
included, whereas in the 'normal' case, you *do* want the correct EOLs
included....
As I said, I can also rev the blame callback api and include the eol
marker in each call to the callback, but that too seems ugly...
bye,
Erik.
Received on Wed Dec 7 12:15:21 2005