Decide where to store test files about rdiff-backup

[ericzolf]

I would keep it as I did it until now (but of course in this repo, not mine), as release with tag meaning basically, at this stage the code / tests worked with those testfiles.

Not a nice alternative but I think the others are worse until we have a better solution:

• packed or unpacked, the files are big and binaries, nothing I'd like to have in our main Git repo.
• unpacked in a separate Git repo: the issue is that the files also contain ACLs, extended attributes, hard and soft links, root and user rights, device & other non regular files, etc i.e. nothing with which Git could cope, and writing a script that would fix all this isn't that easy. And the problem with big binary files and Git remains.
• web page would be an alternative, but again it's a Git repo, etc...

My favoured approach would be to create a script/library which, based on a textual description e.g. YAML, could create any file structure so that we only need to describe which files with need with which characteristics and they would be created on the fly. Not an easy approach but the best IMHO, and the script itself would be small.

I had already started to think about it: ericzolf#20 - wanted also to check if nobody else had the same idea.

[davekempe]

We could use ansible to abstract that away perhaps? or perhaps whole vagrant boxes setup with local/remote different OSes and filesystems? Sol1 is happy to help with hosting - we are just in the process of upgrading our own hosting facilities, so soon should be able to have plenty of resources we can spare.

[ericzolf]

I also thought about Ansible, I should it's my specialty in real life, but I just postponed the topic as it's a big one. It would be cool to have Windows, and MacOS, machines for testing.

But I'd split the topic:

• short term: stay as is, just move release to the official repo
• long term: introduce "test files as code"

[ericzolf]

I would suggest to create a (temporary) Git repo and put the tarball in there. Once we've found a better solution, we can remove the tarball, trim the repo, do whatever. But at least anybody from the project can work on the testfiles and not only me.

Without objections, I'll proceed accordingly.

[ikus060]

I don't understand why you can't keep the targz in the same git repo ? What are your pro / cons ?

Pros to keep test file in rdiff-backup repo:

• The code and the accompany test files are self contains in the same project. No external dependencies.
• Changes done in the code and the test files are in sync.

[ericzolf]

The pros and cons have been listed already in the 3 first comments of the issue, but to answer your question more specifically: big and binary files make a Git repo slow and inefficient (that's why git LFS has been invented).