NAME

SYNOPSIS

DESCRIPTION

It's safe to run in an existing repository (the repository contents are not altered), although it may perform expensive data transfers.

It's best to make a new remote for testing purposes. While the test tries to clean up after itself, if the remote being tested had a bug, the cleanup might fail, leaving test data in the remote.

Testing will use the remote's configuration, automatically varying the chunk sizes, and with simple shared encryption disabled and enabled, and exporttree disabled and enabled. If the remote is readonly, testing is limited to checking various properties of downloading from it.

OPTIONS

--fast

Perform a smaller set of tests.

--test-readonly=file

Normally, random objects are generated for the test and are sent to the remote. When a readonly remote is being tested, that cannot be done, and so you need to specify some annexed files to use in the testing, using this option. Their content needs to be present in the readonly remote being tested, and in the local repository.

This option can be repeated.

--size=NUnits

Tune the base size of generated objects. The default is 1MiB.

Also the git-annex-common-options(1) can be used.

SEE ALSO

git-annex-test(1)

AUTHOR