Greg Hudson wrote:
>On Mon, 2002-10-28 at 18:57, Branko Èibej wrote:
>
>>> * We should always collect line and file information, but only
>>> expose it with the appropriate flag set. This will help with
>>> debugging and will simplify the internal interface.
>>>
>>>
>>No, we should _collect_ it only with the appropriate flag set
>>
>>
>
>Why?
>
Argh, ignore me. My though processes must have fossilized for a moment.
>From a separate message:
>
>
>>I'm sick and tired of how our Python test harness depends on "svn
>>import" working correctly.
>>
>>
>
>I don't see how this is a serious problem.
>
I think it is. For one thing, it slows down the tests (on my machine,
DAV tests -- just the client stuff, without fs-tests -- take almost two
hours...). But more importantly, a bug in "svn import" means that you
get _no_ useful information at all from a test run, and it could
concievably give false passes, not just false failures. It's never a
good idea to use the tool you're testing as part of its test harness.
>But perhaps relying on
>"svnadmin load" would be a good compromise. That way the test harness
>wouldn't rely on as much Subversion machinery working, but the same
>input data would work for any filesystem back end.
>
No, I don't think so. Other FS backends will presumably have their own
dump/load mechanisms, also independent of Subversion, so we can just use
those. When the schema changes, we can just dump a new greek tree, no
problems there.
>My quibble about the test harness is that when a cmdline test fails, I
>can't easily bring up the same command in a debugger to find out what
>went wrong. I'd like it if tests.log contained a log of commands run so
>I can find out which command failed. Plus, if a command seg faults, I'd
>like a note to that effect; as it stands, I get an unexplained "FAIL:"
>and I have to notice the core file lying around.
>
Ah, that can be arranged, certainly.
--
Brane Èibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 29 07:17:35 2002