On 8 January 2015 at 19:04, Peter Kelly <[email protected]> wrote: > > On 8 Jan 2015, at 11:52 pm, jan i <[email protected]> wrote: > > > > I would have assumed that collecting test documents can never be bad. I > am > > not sure I can follow you with "to fork or to fetch". > > > > I believe we need to documents in our test repo, so that developers have > no > > excuse for not running the tests. If I see dftest (and/or dfutil) you can > > setup testcases, that reads the .docx document, generates html, and > checks > > it. > > I'm in favour of having test documents available in a repository, but I'd > just add a word of caution about the amount of data involved. I could see > the test suite potentially reaching several hundred megabytes, and there > are likely to be situations in which someone wants to just check out the > source code, not the whole repository. I think I remember running into this > problem with WebKit once. > > Perhaps we could have a separate corinthia-testdocs repository, and add > that as a git submodule in the main module so that we can ensure the > references from the source repository are to the appropriate commits in the > testdocs repository? > I like that idea very much...that way we have it available, but not disturbing our sources.
I will take a chat with infra, if there are any problems in doing that. Rgds jan i > > Currently all the data tests are in a text-based format and easily > compressed, but if we start adding binary files then space/bandwidth could > quickly start becoming an issue. Additionally, someone working on one > particular filter might not want to download 300+Mb of files from other > filters that their changes are not going to affect. > > — > Dr Peter M. Kelly > [email protected] > > PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key> > (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966) > >
