From 69546f73caee75db8b196201f786ea0aa93c1fe7 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 8 Apr 2024 16:57:53 -0400 Subject: [PATCH] comment --- ..._d944fd707130be6ebe35302794a0b73f._comment | 24 +++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 doc/todo/Idea_for_emulating_a_versioned_tree_export/comment_1_d944fd707130be6ebe35302794a0b73f._comment diff --git a/doc/todo/Idea_for_emulating_a_versioned_tree_export/comment_1_d944fd707130be6ebe35302794a0b73f._comment b/doc/todo/Idea_for_emulating_a_versioned_tree_export/comment_1_d944fd707130be6ebe35302794a0b73f._comment new file mode 100644 index 0000000000..dba76ec6b8 --- /dev/null +++ b/doc/todo/Idea_for_emulating_a_versioned_tree_export/comment_1_d944fd707130be6ebe35302794a0b73f._comment @@ -0,0 +1,24 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2024-04-08T20:46:26Z" + content=""" +When we were talking about this idea, I thought there was a problem, but +didn't quite manage to find it then. + +I see it now: If `foo` is an annexed file that gets exported +this way to `foo/SHA--x`, and then that annexed file +is deleted and a new annexed file `foo/SHA--x` is added, +it will want to export it to `foo/SHA--x/SHA--y`. + +It would either fail because the file exists, or delete it and replace +it with the directory. The former would cause the export to fail, the +latter could case data loss. It's not defined what a special remote will do +in this situation. + +It seems that this case would never occur accidentially, but it's still worth +considering it. + +Perhaps it should simply skip exporting any files that have names +that look like annex keys. +"""]]