From 4fa58ab0190ecb882fc7213ab4dda115dfdda64f Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 22 Sep 2015 15:07:23 -0400 Subject: [PATCH] comment --- ..._0d53226a3991e3685d1311e4b19c4023._comment | 55 +++++++++++++++++++ 1 file changed, 55 insertions(+) create mode 100644 doc/bugs/present_files__47__directories_are_dropped_after_a_sync/comment_3_0d53226a3991e3685d1311e4b19c4023._comment diff --git a/doc/bugs/present_files__47__directories_are_dropped_after_a_sync/comment_3_0d53226a3991e3685d1311e4b19c4023._comment b/doc/bugs/present_files__47__directories_are_dropped_after_a_sync/comment_3_0d53226a3991e3685d1311e4b19c4023._comment new file mode 100644 index 0000000000..a048d31b5d --- /dev/null +++ b/doc/bugs/present_files__47__directories_are_dropped_after_a_sync/comment_3_0d53226a3991e3685d1311e4b19c4023._comment @@ -0,0 +1,55 @@ +[[!comment format=mdwn + username="joey" + subject="""complications""" + date="2015-09-22T18:34:43Z" + content=""" +* The "look at incoming merges, and queue downloads of newer versions of + present files" approach needs to do something about the case where + it's not able to successfully download a newer version immediately. + + If it let the merge proceed, the file would end up not being present + anymore, and so a later sync wouldn't know it had been present. + + Failing to get the contents of all changed files could just make the + sync fail before it merges, keeping the tree at the earlier version. + This might be desirable. + + But, implementing that means changing sync to download file contents + before merging, rather than the current merge-first. I'm sure a lot of + people *won't* want that. (Ie, I certianly don't.) So, this seems to need + to be a new mode for syncing. + + (Such a mode is probably generally useful, aside from this use case.) + +* If this was implemented, then when a file is modified, the content + of the new file would be present. git-annex already makes it so that, + when a file is moved, the content of the file is still present. But, + what if a file were first moved and then modified? If that happened in + multiple commits, they could be examined in turn (with additional + complication and slowdown) to conclude that the content is wanted. But if + that happened in a single commit, there's no way to tell that from + deleting the old file and adding a new file, whose content would not be + automatically wanted. + +* The bug report wants git-annex to somehow detect when the user has + manually gotten an entire directory tree and start getting new files in + that directory too, which seems pretty infeasible. How is git-annex + supposed to guess whether you want new files in a directory tree, + or just the files that are currently there? What if some files + are duplicated amoung 2 directory trees, and one tree ends up complete + while the other one doesn't? This seems like a request for mindreading + ponies. + +* There are many preferred content expressions that fully specify what + files are wanted, without using the "present" token. AFAICS, + there's no reason to do any of this work when the preferred content + expression doesn't include "present". + +TBH, I am not at all sure this is implementable anywhere near sanely. +If I were you, I'd use preferred content to specify the files I want, +which avoids these complexities and works great. Using metadata to tag +files and making all tagged files be wanted in the preferred content +expression is one nice way to go. And metadata is copied over when adding +a new version of a file, so this tagging approach works across file +modifications. +"""]]