remove old closed bugs and todo items to speed up wiki updates and reduce size

Remove closed bugs and todos that were last edited or commented before 2017.

Command line used:

for f in $(grep -l '|done\]\]' -- *.mdwn); do d="$(echo "$f" | sed 's/.mdwn$//')"; if [ -z "$(git log --since=01-01-2017 --pretty=oneline -- "$f")" -a -z "$(git log --since=01-01-2017 --pretty=oneline -- "$d")" ]; then git rm -- "./$f" ; git rm -rf "./$d"; fi; done
for f in $(grep -l '\[\[done\]\]' -- *.mdwn); do d="$(echo "$f" | sed 's/.mdwn$//')"; if [ -z "$(git log --since=01-01-2017 --pretty=oneline -- "$f")" -a -z "$(git log --since=01-01-2017 --pretty=oneline -- "$d")" ]; then git rm -- "./$f" ; git rm -rf "./$d"; fi; done

7 files changed, 0 insertions, 107 deletions

diff --git a/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_1_d8ab07429195c06ec4fae199ca9e0764._comment b/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_1_d8ab07429195c06ec4fae199ca9e0764._comment
deleted file mode 100644
index 9fadf817f..000000000
--- a/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_1_d8ab07429195c06ec4fae199ca9e0764._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="209.250.56.54"
- subject="comment 1"
- date="2014-10-06T15:11:18Z"
- content="""
-There might be a general problem with using git-annex against a read-only filesystem, but the specific case here is a read-only filesystem containing a repository in an old format which git-annex needs to upgrade to the current format to use. So it's pretty reasonable that the (automatic) upgrade fails, since it's not being allowed to write to the repository to upgrade it.
-
-Now, if that repository is a indirect mode repo, there is really no change between version 3 and version 5, so it might do to let git-annex ignore the failure to write out the config, and treat that repo as if it's a v5 repo. It seems easier in most cases to mount the media read-write for git-annex to do the upgrade though.
-"""]]
diff --git a/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_2_03c16df9d6c14e1529c5dc8b5fc49691._comment b/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_2_03c16df9d6c14e1529c5dc8b5fc49691._comment
deleted file mode 100644
index 4bd0bce59..000000000
--- a/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_2_03c16df9d6c14e1529c5dc8b5fc49691._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="https://id.koumbit.net/anarcat"
- ip="72.0.72.144"
- subject="comment 2"
- date="2014-10-06T15:18:20Z"
- content="""
-i've seen problems like this not related to upgrades at all, in [[todo/read-only removable drives]]. furthermore, it seems to me that failure to upgrade a repository shouldn't be fatal and we should be able to recover and get files anyways, in the spirit of [[backwards compatibility|future_proofing]]. --[[anarcat]]
-"""]]
diff --git a/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_3_c505a9df0ef63bb7cac28af9502a953d._comment b/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_3_c505a9df0ef63bb7cac28af9502a953d._comment
deleted file mode 100644
index 3fd24eb67..000000000
--- a/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_3_c505a9df0ef63bb7cac28af9502a953d._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="http://joeyh.name/"
- ip="209.250.56.54"
- subject="comment 3"
- date="2014-10-06T15:59:10Z"
- content="""
-From a code complication POV, it's useful for git-annex to only support one version of repository at a time.
-
-As far as backwards compatablity goes, I don't anticipate ever removing the upgrade code from git-annex. It still supports upgrading v0 repos which probably only I ever used!
-"""]]
diff --git a/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_4_2491fabe2eb7a14bfef0e388b4b9c4c7._comment b/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_4_2491fabe2eb7a14bfef0e388b4b9c4c7._comment
deleted file mode 100644
index 8543aaad7..000000000
--- a/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_4_2491fabe2eb7a14bfef0e388b4b9c4c7._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="anarcat"
- ip="70.83.139.100"
- subject="comment 4"
- date="2014-10-30T15:22:32Z"
- content="""
-the problem here is that it upgrading the repo will not work on a readonly filesystem, so we can't upgrade, we can't get files, so we can't sync.
-
-we should be able to sync anyways - can't we try our best shot at getting files even without upgrading the metadata? i mean i'm looking for something in .git/annex/objects/, maybe i don't care about tracking so much - i just want to recover some files... 
-"""]]
diff --git a/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_5_07f612d7059a9b561c48d63e471d5ed7._comment b/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_5_07f612d7059a9b561c48d63e471d5ed7._comment
deleted file mode 100644
index 24b7dd118..000000000
--- a/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_5_07f612d7059a9b561c48d63e471d5ed7._comment
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!comment format=mdwn
- username="http://jaen.saul.ee/id/"
- nickname="Jaen"
- subject="Re: why this happened"
- date="2014-10-30T19:04:56Z"
- content="""
-I agree that at least read-only support should be there. This error was from an filesystem type that is impossible to mount read-write.
-
-Now that I am looking at it again with fresh eyes, I suppose it's possible to get around this by mounting an union filesystem with a read-write temp layer on top of the read-only one (not that a regular user would ever figure that out...)
-"""]]
diff --git a/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_6_c469f1fe8ae6981a038be7f8723a07b1._comment b/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_6_c469f1fe8ae6981a038be7f8723a07b1._comment
deleted file mode 100644
index fac28c24d..000000000
--- a/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_6_c469f1fe8ae6981a038be7f8723a07b1._comment
+++ /dev/null
@@ -1,7 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 6"""
- date="2014-10-31T16:55:47Z"
- content="""
-An upgrade could move the annexed objects around.
-"""]]
diff --git a/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_7_864d4b5c207dce19d017b3e7608531f8._comment b/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_7_864d4b5c207dce19d017b3e7608531f8._comment
deleted file mode 100644
index 25464816e..000000000
--- a/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_7_864d4b5c207dce19d017b3e7608531f8._comment
+++ /dev/null
@@ -1,52 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 7"""
- date="2016-10-05T20:29:56Z"
- content="""
-I've made V3 repositories be supported to use without an upgrade, so
-that fixes the specific case this bug report was filed about.
-
-----
-
-I do not, however, want to commit to git-annex supporting use of all past
-repo versions without an upgrade process. The point of the upgrade process
-is to keep code complication down. 
-
-All the code that knows about V1 is in Upgrade.V1, and the rest of
-git-annex does not need to check the repo version when doing things
-with annex objects in order to support the different V1 location. 
-Supporting accessing content from V1 repositories without an upgrade would
-lose this clean separation and complicate an unknown number of places in
-git-annex. And any of those places that would have to include a check to
-handle V1 would be liable to break as the code was changed, without anyone
-except the rare V1 user likely to notice.
-
-V1 was the last upgrade to change the locations of annexed objects, and
-there's now the tuning interface that might be used for such future
-location changes, but that's not the only kind of change that an upgrade
-might deal with, and making a commitment that all future versions of
-git-annex will support getting annexed objects from V5 (and V6 and V3)
-would really narrow down the kinds of changes that could ever be made to
-the git annex repository format, and I don't want to do that.
-
-Supporting upgrades from all past versions is sufficient for future
-proofing. It doesn't guarantee super easy use of an old repo from some old
-version of git-annex. 
-
-... You might have to copy it from its original rusty
-media to some tiny corner of a far-future storage crystal, in order for
-git-annex to be able to write to the repository when it upgrades to V7
-without disturbing the original rusty media.
-
-.. And git-annex may need to do arbitrary amounts of work, since V7 turned
-out to also entail a switch from the broken-in-2100 SHA2 to a new
-quantum-computer-safe hash. 
-
-.. And git may also need to do similar work to upgrade the old repository
-from the (broken-in-2010) SHA1 to its new hash. (Hopefully git will support
-upgrading from old repo versions at least as well as git-annex does!)
-
-The important thing is to have a upgrade path that is guaranteed to
-be supported all the way into the future, and I've made the best choices I
-can to ensure that.
-"""]]