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

Re: extending the blame callback

From: Julian Foad <julianfoad_at_apache.org>
Date: Fri, 18 Jan 2019 12:48:03 +0000

Stefan Kueng wrote:
> On 14.01.2019 14:25, Branko Čibej wrote:
> > I started on that then decided that svn_client_blame6 is far too narrow
> > scope for that. In order to do this right, we have to introduce a line
> > splitter callback to svn_subst_stream_translated.
> >
> > My idea was to do something like this:
> >
> > * If the line-splitter is NULL, use the current default and check MIME
> > type for text/*
> > * If it's not NULL, ignore MIME type and provide the callback with
> > file props so it can use that to determine encoding if it wants to.
> > * Remove the ignore_mime_type flag and use the presence of a line
> > splitter to convey the same intent; consequently,
> > * Expose the "default" line splitter as a public function.
>
> one problem I encountered so far is that the encoding detection requires
> data to work properly. But if e.g. the first few lines of a file have
> only a few chars, then that's not enough.
> Not sure how this could be done, but since the blame function already
> has the file loaded into memory, could this be passed to the client in
> any way? Maybe the first time the callback is called? Or on every call?
> What I mean is instead of passing the svn_string_t for only a line, pass
> it for the whole (unmodified/untranslated) file too.

Hi, Stefan. It wouldn't make sense to try to do this detection in the "blame line" callback: that is far too late. That's why we're discussing introducing a new "stream translation" callback, which would not be specific to "blame" but used for all textual operations.

There was some more discussion about it on #svn-dev [1], but not any good conclusions yet.

A stream translation callback could act as a stream filter, before the line splitting occurs, and could be responsible for determining how to translate both the character encoding and the keywords and EOL style. It could be free to buffer and examine as much of the file content as it wants to, before it starts to output the translated file content.

I'd be very glad to see any prototypes of such ideas.

-- 
- Julian
[1] 2019-01-14 Discussion of line-splitter callback ideas on #svn-dev, archived at https://colabti.org/irclogger/irclogger_log/svn-dev?date=2019-01-14#l50 and on Matrix: https://matrix.to/#/!hFVJYCuSnqoHmiVQYA:matrix.org/$15474728952387759JdjHl:matrix.org?via=matrix.org&via=foad.me.uk
Received on 2019-01-18 13:48:12 CET

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.