[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Fixing blame's eol sensitivity (plans for the last round)

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2005-12-07 11:31:19 CET

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

> 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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.