From cb54d37556bd22e53355a603a801d72dcf228960 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 7 Sep 2017 16:07:28 -0400 Subject: update --- .../comment_2_7fbbc5beb80acf32eff617ec704d5466._comment | 13 ++++++++++--- doc/todo/export.mdwn | 12 ++++++++++++ 2 files changed, 22 insertions(+), 3 deletions(-) (limited to 'doc') diff --git a/doc/devblog/day_468__export_renames/comment_2_7fbbc5beb80acf32eff617ec704d5466._comment b/doc/devblog/day_468__export_renames/comment_2_7fbbc5beb80acf32eff617ec704d5466._comment index fcd1eb66c..1dfdfe6de 100644 --- a/doc/devblog/day_468__export_renames/comment_2_7fbbc5beb80acf32eff617ec704d5466._comment +++ b/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. """]] diff --git a/doc/todo/export.mdwn b/doc/todo/export.mdwn index c4e57bd1c..7a94cd1c8 100644 --- a/doc/todo/export.mdwn +++ b/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? -- cgit v1.2.3