todo/add tests under concurrencygit-annexhttp://git-annex.branchable.com/todo/add_tests_under_concurrency/git-annexikiwiki2019-05-09T21:07:39Zcomment 1http://git-annex.branchable.com/todo/add_tests_under_concurrency/comment_1_9879c63f9de342b6831d5794d8f6212e/joey2019-01-21T15:42:51Z2018-12-09T14:47:59Z
<p>As the test suite is constructed, there is a single origin repository
shared by clones used for each test case, and there are test cases that do
eg <code>git annex move --from origin ; git annex move --to origin</code> and so would break
other tests cases using the same origin if they were run concurrently, without it
being an actual concurrency bug in git-annex.</p>
<p>So parallelizing the test suite would need each test case to have its own
isolated set of test repos. But then concurrency bugs could not be found by
the test suite; concurrency would only possibly make it run faster.</p>
<p>Finding concurrency bugs seems to need the test repos to contain more
files than the two or three they now do, so that a single test case can
run some git-annex operation concurrently on several files at once.</p>
<p>Also, if you look at the CHANGELOG, you'll find that concurrency bugs in
git-annex beyond the UI level are fairly rare. And I can think of only one
concurrency bug that ever caused even theoretical data loss; it involved 3
repos in a triangle topology all dropping the same file at the same time.</p>
comment 2http://git-annex.branchable.com/todo/add_tests_under_concurrency/comment_2_3713c706c8a0689f527c4558176a7b48/Ilya_Shlyakhter2019-05-09T21:07:39Z2019-05-09T21:07:38Z
<p>"Finding concurrency bugs seems to need the test repos to contain more files than the two or three" -- it should be enough to run a concurrent operation many times on a small repo. This will test the different possible orders of operation. Most concurrency bugs only involve a conflict of two or three operations.</p>
<p>Running under something like https://rr-project.org/ can be used to reliably reproduce concurrency bugs.</p>
<p>"I can think of only one concurrency bug that ever caused even theoretical data loss" -- that's good. But beyond data loss, when a complex operation fails in the middle, it can be non-trivial to figure out which parts to redo.</p>