Current Trajectory
==================
-Now that we've finished the 0.26 release, we're working on 0.27, and
-although we're not certain which new features will be included, here
-are some possible candidates:
-
- - Support for transferring saves between repositories and rewriting
- branches.
+Now that we've finished the 0.31 release, we're working on 0.32, and
+although we're not certain which new features will be included, we're
+considering:
- Better VFS performance for large repositories (i.e. fuse, ls,
web...).
- - Incremental indexing via inotify.
+ - Better VFS caching.
- - Support for rm/gc.
+ - Index improvements.
+
+ - Incremental indexing via inotify.
- Smarter (and quieter) handling of cross-filesystem metadata.
+ - Encryption.
+
+ - Support for alternate remote storage APIs.
+
If you have the time and inclination, please help review patches
posted to the list, or post your own. (See "ways to help" below.)
We also love a good "Tested-by:" -- the more the merrier.
+Testing
+=======
+
+You can run the test suite much more quickly via "make -j test" (as
+compared to "make test"), at the expense of slightly more confusing
+output (interleaved parallel test output), and inaccurate intermediate
+success/failure counts, but the final counts displayed should be
+correct.
+
+Individual non-Python tests can be run via
+
+ ./wvtest run test/ext/TEST
+
+and if you'd like to see all of the test output, you can omit the
+wvtest run wrapper: `test/ext/TEST`. Individual Python tests can be
+run via
+
+ ./pytest test/int/test_something.py
+
+Internal tests that test bup's code directly are located in test/int,
+and external tests that test bup from the outside, typically by
+running the executable, are located in test/ext.
+
+
+Some aspects of the environment are automatically restored after each
+test via fixtures in conftest.py, including the state of the
+environment variables and the working directory; the latter is reset
+to the top of the source tree.
+
Submitting patches
==================
As mentioned, all patches should be posted to the mailing list for
review, and must be "signed off" by the author before official
inclusion (see ./SIGNED-OFF-BY). You can create a "signed off" set of
-patches in ./pending, ready for submission to the list, like this:
+patches in ./patches, ready for submission to the list, like this:
git format-patch -s -o patches origin/master
locally, you may need to configure git to be able to send mail. See
git-send-email(1) for further details.
-Oh, and we do have a ./CODING-STYLE, hobgoblins and all, though don't
+Oh, and we do have a ./CODINGSTYLE, hobgoblins and all, though don't
let that scare you off. We're not all that fierce.