Merge branch 'master' of ssh://git-annex.branchable.com

2 files changed, 26 insertions, 0 deletions

diff --git a/doc/todo/New_special_remote_suggeston_-_clean_directory/comment_5_8d6c791e5e2daec7b25828f6884a67c6._comment b/doc/todo/New_special_remote_suggeston_-_clean_directory/comment_5_8d6c791e5e2daec7b25828f6884a67c6._comment
new file mode 100644
index 000000000..f87bf1aec
--- /dev/null
+++ b/doc/todo/New_special_remote_suggeston_-_clean_directory/comment_5_8d6c791e5e2daec7b25828f6884a67c6._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.64"
+ subject="comment 5"
+ date="2013-12-05T19:52:52Z"
+ content="""
+Comment #1 was my initial reaction. A regular direct mode git-annex repository on the mounted NAS share.
+
+I don't quite understand the response to it \"that'd limit me to being on the local network when I want to interact with the repo\". How could git-annex update this NAS if it's not on the local network?
+
+So far, the only reason that has been brought up that makes sense to me is locking. git-annex does use locking in its repository to prevent 2 git-annex commands run at the same time doing conflicting operations. (Lack of that locking could in some cases cause data loss.) I think git-annex's locking is limited entirely to files within the .git directory. So, if a SMB mount for a NAS does not support locking, one approach could be to move the .git directory to local disk, and use `GIT_DIR` to make it be used when operating in that repository. This should get you exactly what was requested. Whether it makes sense or is sufficiently easy to use is another question.
+
+I tend to think that a better use of a NAS in many cases is to put a directory or rsync (if it supports rsync) special remote on the NAS, and have git-annex on the individual client machines. The webapp could have a UI that makes setting up a NAS like that simple, and it would be easy to do.
+
+The use case for having a mirrored directory tree on the NAS seems to be limited to when the clients using it are something that cannot run git-annex itself, but that still cares about filenames, as opposed to just operating on file contents.
+"""]]
diff --git a/doc/todo/New_special_remote_suggeston_-_clean_directory/comment_6_92ef2d4a7ed47000fda02732b4794dc0._comment b/doc/todo/New_special_remote_suggeston_-_clean_directory/comment_6_92ef2d4a7ed47000fda02732b4794dc0._comment
new file mode 100644
index 000000000..75614d69f
--- /dev/null
+++ b/doc/todo/New_special_remote_suggeston_-_clean_directory/comment_6_92ef2d4a7ed47000fda02732b4794dc0._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.64"
+ subject="comment 6"
+ date="2013-12-05T19:57:32Z"
+ content="""
+The other problem with this idea is that it seems to want the assistant to watch the file tree in the NAS, and make commits etc when files there are changed.
+
+But, any computer on the network that has the NAS mounted can change a file! AFAIK there is no interface to detect when such changes have happened; inotify does not help. It seems git-annex would have to expensively periodically scan the directory to find changes.
+"""]]