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

Re: diff4-optimization-bytes

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Wed, 9 Feb 2011 11:20:09 +0200

In other news, I looked into the cause --- tried to make
datasource_get_next_token() do one more loop in the place where
currently it does 'return if at_start_of_suffix()' --- but that didn't
fix the truncation...

In the meantime, I tweaked a test to make it XFail (r1068798). From
a quick glance it seemed to be relevant, but in second thought I'll
admit I didn't study the test thoroughly before making the patch.

Daniel

Daniel Shahaf wrote on Wed, Feb 09, 2011 at 11:10:43 +0200:
> Johan Corveleyn wrote on Wed, Feb 09, 2011 at 08:42:20 +0100:
> > On Wed, Feb 9, 2011 at 4:54 AM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> > > The experimental code is svn_diff_diff4_2(); AFAIK svn_diff_diff4() is
> > > as stable as ever.
> >
> > I have no objections on adding such an annotation. However, from where
> > I'm sitting, svn_diff_diff4() is/was just as under-exercised as
> > svn_diff_diff4_2(), i.e. no known callers, only one unit test (thanks
> > for adding that test, BTW). Of course it's into the codebase a lot
> > longer than *_2, but it has never had any core code calling it, and no
> > unit tests (so could have been broken by any number of commits after
> > its inception till now).
> >
>
> In other words, svn_diff_diff4() is as experimental as svn_diff_diff4_2().
> Agreed.
>
> IMO the issue boils down to representation: if we haven't tested a given
> piece of code (it has no callers and a surfacial unit test), then we
> shouldn't represent to API consumers otherwise.
>
> Daniel
> (and yes, I respect all the work you've been doing; my opinion of
> diff4_2() is orthogonal to that)
>
> > --
> > Johan
Received on 2011-02-09 10:25:09 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.