From 2d9b3e45106d2e8086f8c5db287ed77d860f9bf6 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sun, 9 Dec 2018 11:11:53 -0400 Subject: [PATCH] comment --- ..._9879c63f9de342b6831d5794d8f6212e._comment | 24 +++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 doc/todo/add_tests_under_concurrency/comment_1_9879c63f9de342b6831d5794d8f6212e._comment diff --git a/doc/todo/add_tests_under_concurrency/comment_1_9879c63f9de342b6831d5794d8f6212e._comment b/doc/todo/add_tests_under_concurrency/comment_1_9879c63f9de342b6831d5794d8f6212e._comment new file mode 100644 index 0000000000..e332fda02a --- /dev/null +++ b/doc/todo/add_tests_under_concurrency/comment_1_9879c63f9de342b6831d5794d8f6212e._comment @@ -0,0 +1,24 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2018-12-09T14:47:59Z" + content=""" +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 `git annex move --from origin ; git annex move --to origin` 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. + +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. + +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. + +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. +"""]]