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

5 files changed, 54 insertions, 0 deletions

diff --git a/doc/bugs/copy_unused_and_unused_not_agreeing/comment_3_9b1340e0f6a107695849c04374aaeae2._comment b/doc/bugs/copy_unused_and_unused_not_agreeing/comment_3_9b1340e0f6a107695849c04374aaeae2._comment
new file mode 100644
index 000000000..4fb2b3d39
--- /dev/null
+++ b/doc/bugs/copy_unused_and_unused_not_agreeing/comment_3_9b1340e0f6a107695849c04374aaeae2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://grossmeier.net/"
+ nickname="greg"
+ subject="comment 3"
+ date="2014-02-20T19:31:56Z"
+ content="""
+heh, I *just* dist-upgraded this morning on the box that was showing the problem from git-annex_5.20140127_amd64.deb to git-annex_5.20140210_amd64.deb. So what you say is probably right (re unused.log).
+
+The only other annex I have in direct mode right now is one that I also am using the standalone build with (version 5.20131224-g6ca5271 right now). It has unused content in it (in fact, it's the synology annex, where I'm moving all the unused data to). I can do testing there if needed (and since it's a standalone build, it's easy for me to switch around git-annex versions with symlinks). The only problem is that it is dog slow when running git-annex unused. :)
+"""]]
diff --git a/doc/bugs/git_annex_sync_--content_not_syncing_all_objects/comment_1_36deea0f1277d6888c8bb79156c56efa._comment b/doc/bugs/git_annex_sync_--content_not_syncing_all_objects/comment_1_36deea0f1277d6888c8bb79156c56efa._comment
new file mode 100644
index 000000000..e395eac0e
--- /dev/null
+++ b/doc/bugs/git_annex_sync_--content_not_syncing_all_objects/comment_1_36deea0f1277d6888c8bb79156c56efa._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.172"
+ subject="comment 1"
+ date="2014-02-20T19:34:29Z"
+ content="""
+Yep, sync --content only looks at the work tree. 
+
+I suppose that the assistant does a better job in this situation, since if it cannot access an archive repo, it will remember that it tried to send a file to it, and retry that transfer later -- even if in the meantime the file has gotten deleted out of the work tree (and still has content present, due to using indirect mode). I'm actually not 100% sure .. the assistant may give up on transferring a file if it's gotten removed from the work tree. It's worth considering this because I basically want sync --content to do the same syncing that the assistant does.
+
+Anyway, sync --content could certianly look at all keys present in the annex. This would require a separate pass, and it might then try to upload a key twice, once from work tree, and once from annex, and fail twice. 
+
+Maybe it would be better to have this as a separate --content --all. It might also make sense to keep sync --content only looking at the work tree by default to support cases where there are multiple branches and you only want to sync one.
+
+I think this needs more thought.
+"""]]
diff --git a/doc/forum/not_finding_git-annex-shell_on_remote/comment_4_71ae60efcacdba5e11548923b2c85b95._comment b/doc/forum/not_finding_git-annex-shell_on_remote/comment_4_71ae60efcacdba5e11548923b2c85b95._comment
new file mode 100644
index 000000000..12bf8fa75
--- /dev/null
+++ b/doc/forum/not_finding_git-annex-shell_on_remote/comment_4_71ae60efcacdba5e11548923b2c85b95._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.172"
+ subject="comment 4"
+ date="2014-02-20T19:41:05Z"
+ content="""
+@Srinath I wonder if the machine you are running git-annex sync on is a Windows machine? I have seen that \" refs/remotes/origin/synced/master - not something we can merge\" intermittently when testing on Windows, but not other times.
+
+(It's not related to the original PATH configuration problem on your server.)
+"""]]
diff --git a/doc/tips/using_Amazon_Glacier/comment_2_d34e05f9244d3a4fcec87b3c360adb4e._comment b/doc/tips/using_Amazon_Glacier/comment_2_d34e05f9244d3a4fcec87b3c360adb4e._comment
new file mode 100644
index 000000000..ed482906b
--- /dev/null
+++ b/doc/tips/using_Amazon_Glacier/comment_2_d34e05f9244d3a4fcec87b3c360adb4e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.172"
+ subject="comment 2"
+ date="2014-02-20T19:24:09Z"
+ content="""
+@greg, the only thing you might have missed is the need to use `glacier vault sync` to build a cache if enabling the glacier remote in another place. And that whole issue with it needing a local cache may mean few people are using glacier with more than one repository accessing the remote.
+
+However, this sounds like a bug. There is a comment in the source code that \"glacier vault create will succeed even if the vault already exists.\" .. perhaps it has changed since that was written. Or perhaps the command failed for some other reason, I don't know.
+"""]]
diff --git a/doc/tips/using_Amazon_Glacier/comment_3_4c504fd22775afe36296cf54d3e04a8e._comment b/doc/tips/using_Amazon_Glacier/comment_3_4c504fd22775afe36296cf54d3e04a8e._comment
new file mode 100644
index 000000000..a8c765bcb
--- /dev/null
+++ b/doc/tips/using_Amazon_Glacier/comment_3_4c504fd22775afe36296cf54d3e04a8e._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.172"
+ subject="comment 3"
+ date="2014-02-20T19:34:48Z"
+ content="""
+I've changed it to avoid running glacier value create when enabling an existing glacier remote. Hopefully that fixes it.
+"""]]