update

1 files changed, 8 insertions, 12 deletions

diff --git a/doc/bugs/backend_version_upgrade_leaves_repo_unusable.mdwn b/doc/bugs/backend_version_upgrade_leaves_repo_unusable.mdwn
index 7bbd02364..64c18f202 100644
--- a/doc/bugs/backend_version_upgrade_leaves_repo_unusable.mdwn
+++ b/doc/bugs/backend_version_upgrade_leaves_repo_unusable.mdwn
@@ -46,17 +46,13 @@ Running the copy job again, I am still getting the same error as above (as expec
 >>>
 >>> That's a v1 key, but a corrupt form of the key; it's missing the 
 >>> size and mtime fields that all WORM keys have in v1. And 
->>> the filename is itself a key, a v2 SHA512 key. My guess at what
->>> happened is that these were created when you did the `git annex copy`
->>> to the v1 bare repo.
+>>> the filename is itself a key, a v2 SHA512 key. These were
+>>> created when you did the `git annex copy to the v1 bare repo.
+>>> In v2, git-annex-shell takes a full key object, while in v1,
+>>> it takes a key name and a backend name. This incompatability
+>>> leads to the weird behavior seen.
 >>>
->>> So, assuming none of these are the only copy of your data
->>> (which you should check), the best thing to do is delete those
->>> keys, and re-run the copy now that it's upgraded. Not sure 
->>> it even makes sense to fix the crash. I should probably focus
->>> on fixing what let these mixed keys be created by the mixed-version
->>> copy.
->>>
->>> On second thought, you shouldn't delete anything. I'll simply
->>> make the v2 upgrade detect and work around this bug.
+>>> I had suggested you delete data.. don't. On second thought,
+>>> you shouldn't delete anything. I'll simply make the v2 upgrade
+>>> detect and work around this bug.
 >>> --[[Joey]]