From ea445260baf4e6119189f0bbd26b08b1274041a0 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 24 Aug 2022 13:13:45 -0400 Subject: [PATCH] comment --- ..._9dc28d46dfcd693def4cbb3837de55e0._comment | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 doc/todo/add_testremote_cleanup/comment_1_9dc28d46dfcd693def4cbb3837de55e0._comment diff --git a/doc/todo/add_testremote_cleanup/comment_1_9dc28d46dfcd693def4cbb3837de55e0._comment b/doc/todo/add_testremote_cleanup/comment_1_9dc28d46dfcd693def4cbb3837de55e0._comment new file mode 100644 index 0000000000..4da49321e1 --- /dev/null +++ b/doc/todo/add_testremote_cleanup/comment_1_9dc28d46dfcd693def4cbb3837de55e0._comment @@ -0,0 +1,19 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2022-08-24T17:05:50Z" + content=""" +Like the man page for this command says, it's best to make a new remote for +testing purposes, not use a production one. + +I think that a simple improvement to it would be for it to generate the +same test keys every time. Then if it failed once or was interrupted or +the remote was buggy, once that got fixed the same command could be run +again, and would clean up the test keys that were earlier stored on the +remote. + +It's generating random data and a key from that, +but a predictable random data would not impair the test really. +Although testExportTree currently starts with a test that might fail +if the key is already present in the remote. +"""]]