[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: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2005-12-07 12:23:54 CET

On Wed, 7 Dec 2005, Erik Huelsmann wrote:

> On 12/7/05, Julian Foad <julianfoad@btopenworld.com> wrote:
> Erik Huelsmann wrote:
> > 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

As far as I remember, we don't output the lines in XML at all because of
encoding issues. And if we did, why wouldn't we want the EOL markers in
the XML output?

>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...

Why is that ugly? Isn't the eol marker part of the line?


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 7 12:25:31 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.