[PATCH 1/2] test: add more informative titles to restore --accumulate tests

Tomi Ollila writes: > > LGTM -- with an added bonus of known misspelling gone in commit message ;) > > Tomi pushed both. d

[PATCH 1/2] test: add more informative titles to restore --accumulate tests

On Sat, Nov 17 2012, david at tethera.net wrote: > From: David Bremner > > Thanks to Ethan for the suggestion. > --- LGTM -- with an added bonus of known misspelling gone in commit message ;) Tomi > test/dump-restore |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff

[PATCH 2/2] test: initial performance testing infrastructure.

From: David Bremner This is not near as fancy as as the unit tests, on the theory that the code should typically be crashing when performance tuning. Nonetheless, there is plenty of room for improvement. Several more of the pieces of the test infrastructure (e.g. the option

[PATCH 1/2] test: factor out part of test-lib.sh into test-lib-common.sh

From: David Bremner The idea is to use some of the simpler parts of the test suite infrastructure to help run performance tests. --- test/test-lib-common.sh | 147 +++ test/test-lib.sh| 129

initial attempt at performance testing suite for notmuch.

For a long time we have needed some commone set of tests to measure changes to e.g. tagging and dump/restore. A non-trivial corpus of mail messages is a bit unwieldy to be shipped with the source, so there is a seperate tarball. Currently the tarball for this needs to manually uploaded to the

[PATCH 2/2] test: add nontrivial test for restore --accumulate.

david at tethera.net writes: > From: David Bremner > > It seems we have never tested the case that restore --accumulate > actually adds tags. I noticed this when I started optimizing and no > tests failed. > > The bracketing with "restore --input=dump.expected" are to make sure > we start in a

[PATCH 2/2] test: add nontrivial test for restore --accumulate.

From: David Bremner It seems we have never tested the case that restore --accumulate actually adds tags. I noticed this when I started optimizing and no tests failed. The bracketing with "restore --input=dump.expected" are to make sure we start in a known state, and we leave

[PATCH 1/2] test: add more informative titles to restore --accumulate tests

From: David Bremner Thanks to Ethan for the suggestion. --- test/dump-restore |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/test/dump-restore b/test/dump-restore index f25f7cf..7acf7fe 100755 --- a/test/dump-restore +++ b/test/dump-restore @@

[PATCH 1/2] test: add more informative titles to restore --accumulate tests

From: David Bremner brem...@debian.org Thanks to Ethan for the suggestion. --- test/dump-restore |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/test/dump-restore b/test/dump-restore index f25f7cf..7acf7fe 100755 --- a/test/dump-restore +++ b/test/dump-restore @@

[PATCH 2/2] test: add nontrivial test for restore --accumulate.

From: David Bremner brem...@debian.org It seems we have never tested the case that restore --accumulate actually adds tags. I noticed this when I started optimizing and no tests failed. The bracketing with restore --input=dump.expected are to make sure we start in a known state, and we leave the

Re: [PATCH 2/2] test: add nontrivial test for restore --accumulate.

da...@tethera.net writes: From: David Bremner brem...@debian.org It seems we have never tested the case that restore --accumulate actually adds tags. I noticed this when I started optimizing and no tests failed. The bracketing with restore --input=dump.expected are to make sure we start

Re: [PATCH 1/2] test: add more informative titles to restore --accumulate tests

On Sat, Nov 17 2012, da...@tethera.net wrote: From: David Bremner brem...@debian.org Thanks to Ethan for the suggestion. --- LGTM -- with an added bonus of known misspelling gone in commit message ;) Tomi test/dump-restore |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

initial attempt at performance testing suite for notmuch.

For a long time we have needed some commone set of tests to measure changes to e.g. tagging and dump/restore. A non-trivial corpus of mail messages is a bit unwieldy to be shipped with the source, so there is a seperate tarball. Currently the tarball for this needs to manually uploaded to the

[PATCH 1/2] test: factor out part of test-lib.sh into test-lib-common.sh

From: David Bremner brem...@debian.org The idea is to use some of the simpler parts of the test suite infrastructure to help run performance tests. --- test/test-lib-common.sh | 147 +++ test/test-lib.sh| 129

[PATCH 2/2] test: initial performance testing infrastructure.

From: David Bremner brem...@debian.org This is not near as fancy as as the unit tests, on the theory that the code should typically be crashing when performance tuning. Nonetheless, there is plenty of room for improvement. Several more of the pieces of the test infrastructure (e.g. the option

Re: [PATCH 1/2] test: add more informative titles to restore --accumulate tests

Tomi Ollila tomi.oll...@iki.fi writes: LGTM -- with an added bonus of known misspelling gone in commit message ;) Tomi pushed both. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch

Re: [BUG] Saving attachments containing UTF-8 chars

Tomi Ollila tomi.oll...@iki.fi writes: I can verify this bug: I copied 'rawmail' to my mail store and attempted to 'w' the attacment and got the same result (after notmuch new). The saving code first does notmuch show --format=raw id:508953e6.70...@gmail.com which decodes OK on command