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

Re: svn commit: r1868561 - /subversion/trunk/subversion/tests/cmdline/diff_tests.py

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Fri, 18 Oct 2019 04:37:07 +0000

Nathan Hartman wrote on Fri, Oct 18, 2019 at 00:08:48 -0400:
> On Thu, Oct 17, 2019 at 5:48 PM Daniel Shahaf <d.s_at_daniel.shahaf.name>
> wrote:
> > Good morning Nathan,
> >
> Good morning! Or whatever time it happens to be in your part of the world
> :-)

<https://en.wikipedia.org/wiki/UGT>, fifth sense.

> Unfortunately, instead of reproducing the output shown in SVN-1722,
> it now produces a much longer diff that includes all the files, some
> 60+ lines, and consequently fails the test, but that could be fixed,
> but...
> While I could run 'svn diff -r BASE:HEAD iota' etc., I think that
> would be the wrong thing to do because SVN-1722 is so old that we
> don't know exactly what circumstances used to trigger it. What if
> we change the test to save some milliseconds and end up defeating
> the purpose? I don't know. Do you think it's worth it?

Yes, good point: adding 'iota' there could invalidate the test. The
bug may well have something to do with how the positional arguments,
peg revision, and operative revisions are resolved to an anchor/target
pair for the edit operation [in the sense of an svn_delta_editor_t drive]
in edge cases, such as when the target doesn't exist in one operative revision.

In fact, I wonder what would happen if the test were done in A/B/E. The
difference is that the working copy root does exist at r0, but A/B/E doesn't.

But as Julian said, we're entering the territory of diminishing returns, so
it's up to you whether to continue ironing this one out or move on to other


Received on 2019-10-18 06:37:20 CEST

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.