Greg Stein <gstein@lyra.org> writes:
> I don't see a problem.
>
> Further, I disagree with the notion of disabling it in CVS so that *nobody*
> can run the test, when it would appear to be a problem local to one system.
>
> There's been a lot of "just disable it from the build" recently, it seems.
>
> If you don't want it to build on your machine, then feel free to disable it.
> But disabling it in CVS is something to really think about it.
It's important that the build and test suite be in a happy state in
the repository most of the time, to facilitate parallel development.
If I've checked in code that breaks "make check", then it's going to
be harder for others to test their own changes, even though their own
changes might not be related to what I'm doing.
So disabling a test is often okay, under certain (common)
circumstances:
Most Subversion developers know one or two parts of the code really
well, and are just kind of tourists in the other parts. When you
discover that either the build is broken, or make check is broken, due
to a problem in an area not familiar to you, you generally have two
choices:
1. Debug it, unless you a) are in the middle of something else
right now, or b) believe that the domain expert for that area
of code can fix it in ten seconds, where as it would take you
two hours.
2. Temporarily disable the code that's causing the problem, so
building and "make check" still work; and check it in, so they
work for others too. (Of course, disabling isn't always an
option, it's only doable if there are no significant
dependencies on the code containing the bug.)
I agree that when it appears to be problem local to your system, then
you shouldn't disable it in CVS. But you can't always tell whether
it's local to your own system.
For example, I'm experiencing some bugs in fs-test.c:dir_deltas right
now that looks exactly like bugs other people have easily reproduced
on their systems in the past; so last night (after two hours of
attempting to track it down, using reliable reproduction recipes on my
own machine), I commented the test out and committed that. That way,
at least the test suite was in a passing state.
As it happens, other people are not able to reproduce the dir_deltas
bug, it's only me. But it would have been somewhat inconvenient to
find that out at 10pm last night, whereas commenting out the test is
an almost non-existent inconvenience for the people (Mike Pilato)
working on fs-test.c:dir_deltas -- I mean, it's what, six keystrokes
and a compile to get it back? :-)
I think the guidelines here are:
* If the build and/or "make check" are broken, and you don't have
any reason to suspect they're only broken for you, then do
whatever you think appropriate to make them work again.
* If what you did to make them work was only a temporary solution,
make sure that either you're going to come back and do the Right
Thing later, or that a domain expert knows what's happened so
they can do the Right Thing.
-K
> p.s. yes, I know ra-local-test doesn't actually run any tests right now, but
> that is not the point
>
> On Tue, Mar 27, 2001 at 11:55:14PM -0000, sussman@tigris.org wrote:
> > User: sussman
> > Date: 01/03/27 15:55:14
> >
> > Modified: subversion/tests/libsvn_ra_local Makefile.am
> > Log:
> > Suddenly tests/libsvn_ra_local/ won't build:
> >
> > /usr/libexec/elf/ld: cannot find -lneon
> >
> > Gstein, can you investigate? I'm temporarily disabling this dir's
> > build.
> >
> > Revision Changes Path
> > 1.5 +4 -4 subversion/subversion/tests/libsvn_ra_local/Makefile.am
> >
> > Index: Makefile.am
> > ===================================================================
> > RCS file: /cvs/subversion/subversion/tests/libsvn_ra_local/Makefile.am,v
> > retrieving revision 1.4
> > retrieving revision 1.5
> > diff -u -r1.4 -r1.5
> > --- Makefile.am 2001/03/09 17:53:43 1.4
> > +++ Makefile.am 2001/03/27 23:55:13 1.5
> > @@ -1,7 +1,7 @@
> > ## Makefile.in is generated from this by automake.
> >
> > -noinst_PROGRAMS = ra-local-test
> > -ra_local_test_SOURCES = ra-local-test.c
> > +#noinst_PROGRAMS = ra-local-test
> > +#ra_local_test_SOURCES = ra-local-test.c
> >
> > COMMON_LIBS = @SVN_TESTS_MAIN_LIBS@ \
> > @SVN_TESTS_EDITOR_LIBS@ \
> > @@ -13,7 +13,7 @@
> > @SVN_APR_LIBS@ @SVN_EXPAT_LIBS@ -ldb
> > ## Shouldn't -ldb be added automatically by the autoconf script?
> >
> > -ra_local_test_LDADD = ${COMMON_LIBS}
> > +#ra_local_test_LDADD = ${COMMON_LIBS}
> >
> > ## Flags needed when compiling:
> > INCLUDES = -I$(srcdir)/.. @SVN_INCLUDES@ @SVN_APR_INCLUDES@
> > @@ -25,7 +25,7 @@
> > ## Automatic tests run by `make check` -----------------------------
> >
> > ## A list of test-programs to run. (Each program contains sub-tests.)
> > -SVN_TESTS = ra-local-test
> > +#SVN_TESTS = ra-local-test
> >
> > ## We're overriding automake's own `check' rule, because it's extremely
> > ## inflexible; we want better control over automated-test output.
> >
> >
> >
>
> --
> Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:26 2006