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

Re: [PATCH] Note latent bug in libsvn_wc/diff.c

From: Malcolm Rowe <malcolm-svn-dev_at_farside.org.uk>
Date: 2005-10-09 22:54:47 CEST

On Sat, Oct 08, 2005 at 05:47:53PM +0200, Peter N. Lundblad wrote:
> I see. It might be possible to use the binding tests for this, but I no
> nothing about them. Is the reason you're not fixing the bug that you can't
> test it or is it hard to fix in itself?

A bit of both, I think. I'm not going to try to start fixing it until I
can reproduce the problem, and while I could easily hack my local client
to request a diff of -rWORKING:X, that wouldn't help me when it came
to submitting the patch itself, because I'd need a regression test. The
bug's not trivial either, unless I missed something.

> BTW, I think we need real libsvn_client tests for stuff like this and
> stuff like thi diff_summarize APIs that aren't available through the
> cmdline client (yet).

Agreed. I took a look at this briefly today, but I couldn't come up
with any obviously great solution. As a non-commandline client test, I'd
expect to see it in subversion/tests/, with all the other libsvn_* tests.

However, most of what we'd need to test would require the support code
in tests/cmdline/client anyway, because we'd want to intersperse calls
to svn (for 'add', 'ci', etc) with direct calls to libsvn_client. Anyway,
the commandline tests _are_ pretty much the tests for libsvn_client.

So the best I came up with was this: create a stub client in
subversion/tests/, perhaps based on tools/examples/minimal_client.c,
whose only job is to run svn_client_diff3 against -rWORKING:N, for a
specified N and target. Then call that tool from within diff_tests.py,
just as we'd normally call svn or svnadmin.

And similarly for the diff_summarize work. If at a later date, the svn
client actually gains the ability to call any of those APIs, we retire
the stub client and just replace the call to it with one to svn.

It sucks, but I can't think of anything better.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Oct 9 22:55:35 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.