update

doc/devblog/day_468__export_renames/comment_2_7fbbc5beb80acf32eff617ec704d5466._comment

@@ -13,7 +13,14 @@ efficiently, by moving to the single temp file and copying. Although it
 might still involve the special remote doing more work than strictly
 necessary depending on how it implements copy.
 
-At some point you have to pick simplicity and ability to recover from
-problems over totally optimal speed though, and I think your case is a
-reasonable place to draw the line.
+Anyway, if the user is exporting copys of files, they're probably going to
+care more about that being somewhat more efficient than about renames of
+pairs of those copies being optimally efficient..
+
+Handling it fully optimally, with only one temp file per key,
+would require analizing the change and finding pairs of renames
+that swap filenames and handling each pair in turn. I suppose that
+is doable, just needs a better data structure than I have now.
+I've added a note to my todo list and the design document, but
+no promises.
 """]]

doc/todo/export.mdwn

@@ -26,3 +26,15 @@ Work is in progress. Todo list:
   to get populated based on the export log in these cases.
 * Support export to aditional special remotes (S3 etc)
 * Support export to external special remotes.
+
+Low priority:
+
+* When there are two pairs of duplicate files, and the filenames are
+  swapped around, the current rename handling renames both dups to a single
+  temp file, and so the other file in the pair gets re-uploaded
+  unncessarily. This could be improved.
+
+  Perhaps: Find pairs of renames that swap content between two files.
+  Run each pair in turn. Then run the current rename code. Although this
+  still probably misses cases, where eg, content cycles amoung 3 files, and
+  the same content amoung 3 other files. Is there a general algorythm?