
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.
186
|
Chapter 8: Developer Information
making each set of proposed changes, your Subversion tree should be in a state in
which the software compiles with no warnings.
Subversion has a fairly thorough
*
regression test suite, and your proposed changes
are expected to not cause any of those tests to fail. By running
make check (in Unix)
from the top of the source tree, you can sanity-check your changes. The fastest way
to get your code contributions rejected (other than failing to supply a good log mes-
sage) is to submit changes that cause failure in the test suite.
In the best-case scenario, you will have actually added appropriate tests to that test
suite that verify that your proposed changes actually work as expected. In fact, some-
times the best contribution a person can make is solely the addition of new tests.
You can write regression tests for functionality that currently works in Subversion as
a way to protect against future changes that might trigger failure in those areas. Also,
you can write new tests that demonstrate known failures. For this purpose, the Sub-
version test suite allows you to specify that a given test is expected to fail (called an
XFAIL), and so long as Subversion fails in the way that was expected, a test result of
XFAIL itself is considered a success. Ultimately, ...