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

Re: tree-conflicts: current branches.

From: Branko Čibej <brane_at_xbc.nu>
Date: Wed, 26 Nov 2008 05:53:28 +0100

Neels J Hofmeyr wrote:
> But I'm not running tests all the time... I'm wondering how you guys out
> there handle the tests. Do you run make check or only selected parts of the
> test suite, how often do you run it, how long does it take you to do that

In days long gone when I was committing regularly, I had two simple rules:

    * Make sure everything compiles before each commit
    * Run at least one set of tests before a bigger change, or after
      several smaller ones, or after a day's worth of hacking.

That certainly doesn't cover all the possible bug paths, but does a
fairly good job of it and adds only about an hour per 8-hour hacking
session. The "at least one set" would usually be ra-local, unless I was
banging on network protocols; and the default FS type, unless I was
banging on a/the other FS type.

> and how do you evaluate which test failures were actually introduced by you?

How does that matter? If a test is failing and you understand the cause,
fix it. If you're not sure, ask around; a bug author may show up. When
in doubt, find the commit that triggers the failure; 99% of the time the
author of the commit also caused the failure.

But it's certainly not wrong to fix other people's bugs. :)

> For me a make check is very time-consuming to pull off.

Yes, it can be that. With ramdisks and such you can speed them up

> Instead, I run e.g.
> only the update_tests and switch_tests when I worked on update, but that's
> pretty much it.

That's OK as a smoke-test thing *if* you also run the whole test suite
every once in a while. Use your judgement; but "localized" changes can
have non-obvious side effects.

Frankly, on a project with so many contributors and theoretically no
PHBs breathing down necks, it should be the norm to spend an equal
amount of time on testing (this includes writing test cases) as coding.
it is always a good idea to keep in mind that this is a version control
project, we make our reputation from our users' trust, and a failing
test *can* cause millins of €/$ of damage in fsck'd-up repositories.

-- Brane

To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-26 05:53:45 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.