Difference between revisions of "Test suite results are unwieldy"
| Line 3: | Line 3: | ||
Some suggestions include: | Some suggestions include: | ||
* Do nothing; explain to people that test suite results are very important to ensure correctness, tell them to suffer through transmit times and ask for larger quota | * Do nothing; explain to people that test suite results are very important to ensure correctness, tell them to suffer through transmit times and ask for larger quota | ||
| − | * * That's not a solution. | + | ** That's not a solution. |
* Con't copy test suite results to remote machines by default; only copy them when requested | * Con't copy test suite results to remote machines by default; only copy them when requested | ||
| − | * * This makes it more difficult to run the test suite, which should (ideally) be run every time a new executable has been created for a production run. | + | ** This makes it more difficult to run the test suite, which should (ideally) be run every time a new executable has been created for a production run. |
* tar/gzip test suite results to save disk space, possibly also storing them this way in the SVN repository | * tar/gzip test suite results to save disk space, possibly also storing them this way in the SVN repository | ||
| − | * * This doesn't save transmit time (since rsync already compresses), and (if used in the repository) doesn't allow delta compression | + | ** This doesn't save transmit time (since rsync already compresses), and (if used in the repository) doesn't allow delta compression |
* Combine test suite results from different source trees into a single directory (with soft links or hard links or similarly) | * Combine test suite results from different source trees into a single directory (with soft links or hard links or similarly) | ||
| − | * * This would be an extra step that runs after all files are there, already consuming disk space. | + | ** This would be an extra step that runs after all files are there, already consuming disk space. |
* Use HDF5 instead of ASCII | * Use HDF5 instead of ASCII | ||
| − | * * Binary files are not well handled by SVN. | + | ** Binary files are not well handled by SVN. |
* Combine several ASCII files into one (fewer files are handled more efficiently), e.g. designing a simple ASCII container format for test cases, or even using this format in CarpetIOASCII | * Combine several ASCII files into one (fewer files are handled more efficiently), e.g. designing a simple ASCII container format for test cases, or even using this format in CarpetIOASCII | ||
| − | * * Wouldn't save disk space. | + | ** Wouldn't save disk space. |
* Use a different ASCII format that doesn't store 13 columns for 1 data field | * Use a different ASCII format that doesn't store 13 columns for 1 data field | ||
| − | * * Maybe we could use the ygraph format? | + | ** Maybe we could use the ygraph format? |
Revision as of 10:13, 14 October 2011
They consume disk space, they consume time when downloading and when copying to a remote machine. People view them as "unimportant" (when compared to source files), and are generally annoyed. What can we do about this?
Some suggestions include:
- Do nothing; explain to people that test suite results are very important to ensure correctness, tell them to suffer through transmit times and ask for larger quota
- That's not a solution.
- Con't copy test suite results to remote machines by default; only copy them when requested
- This makes it more difficult to run the test suite, which should (ideally) be run every time a new executable has been created for a production run.
- tar/gzip test suite results to save disk space, possibly also storing them this way in the SVN repository
- This doesn't save transmit time (since rsync already compresses), and (if used in the repository) doesn't allow delta compression
- Combine test suite results from different source trees into a single directory (with soft links or hard links or similarly)
- This would be an extra step that runs after all files are there, already consuming disk space.
- Use HDF5 instead of ASCII
- Binary files are not well handled by SVN.
- Combine several ASCII files into one (fewer files are handled more efficiently), e.g. designing a simple ASCII container format for test cases, or even using this format in CarpetIOASCII
- Wouldn't save disk space.
- Use a different ASCII format that doesn't store 13 columns for 1 data field
- Maybe we could use the ygraph format?
