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

6 files changed, 174 insertions, 0 deletions

diff --git a/doc/bugs/Crash_when_disabling_syncing_in_the_webapp.mdwn b/doc/bugs/Crash_when_disabling_syncing_in_the_webapp.mdwn
new file mode 100644
index 000000000..e69a145a6
--- /dev/null
+++ b/doc/bugs/Crash_when_disabling_syncing_in_the_webapp.mdwn
@@ -0,0 +1,23 @@
+### Please describe the problem.
+The watcher crashes.
+
+I only need to restart the thread in the pop-up to get everything to work again, but I'm reporting just in case that this issue has any other implications.
+
+
+### What steps will reproduce the problem?
+I open the webapp and in the minutes before it starts syncing (syncing is enabled) I disable it (clicking in the 'syncing enabled' text).
+
+This produces a crash every time.
+
+
+### What version of git-annex are you using? On what operating system?
+5.20140320 in Debian sid and testing
+
+
+### Please provide any additional information below.
+This is all I can see in the logs
+
+[[!format sh """
+Watcher crashed: PauseWatcher
+[2014-03-26 08:54:57 CET] Watcher: warning Watcher crashed: PauseWatcher
+"""]]
diff --git a/doc/bugs/Fix_to_thaoe_remote_to_work_with_latest_tahoe-lafs___40__v._1.10.0__41__.mdwn b/doc/bugs/Fix_to_thaoe_remote_to_work_with_latest_tahoe-lafs___40__v._1.10.0__41__.mdwn
new file mode 100644
index 000000000..974324c30
--- /dev/null
+++ b/doc/bugs/Fix_to_thaoe_remote_to_work_with_latest_tahoe-lafs___40__v._1.10.0__41__.mdwn
@@ -0,0 +1,45 @@
+### Please describe the problem.
+Just a small patch to Tahoe.hs which fixes "initremote repo
+type=thaoe" when using the latest tahoe-lafs release available for
+download.
+
+I'm trying to add an attachment here but the UI says "prohibited by 
+allowed_attachments (user is not an admin)" so please have a look also 
+here: <https://github.com/joeyh/git-annex/pull/21>
+
+### What steps will reproduce the problem?
+
+1. Install latest tahoe-lafs
+2. run "TAHOE_FURL=... git annex initremote repo type=tahoe"
+
+### What version of git-annex are you using? On what operating system?
+
+OS: Debian Sid updated to latest packages
+git-annex: version 5.20140306 
+
+### Please provide any additional information below.
+
+I would like to add few things if i'm able (it's my first time for
+haskell, and I'm a bit lost as now):
+
+1. add an optional parameter or envvar for a root dir cap and switch
+from storing anonymous files to saving a tree of dirs and files
+(much like the webdav back-end) so that i can later renew the
+leases on the files to prevent tahoe's garbage collection process
+expiration (for details see
+<https://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/garbage-collection.rst#client-side-renewal>)
+
+The poor man way to that without touching git-annex is to in some
+way collect the caps of the files from annex metadatas and to link
+them to a directory, which where i can then run "tahoe deep-check
+--add-lease" on;
+
+2. add convergence as an optional parameter. As of now many of the
+files that i'm willing to manage with git-annex are already on my
+grid, mostly because i've used tahoe's backup command to upload
+them in the past. By using the same convergence value that i've
+already setup on my other tahoe client installation i would be able
+to save much time and space by avoiding duplicates.
+
+Do you have any good pointers to pieces code of git-annex that i can
+read and hack to try to implement this or any other suggestion?
diff --git a/doc/bugs/__96__git_annex_forget_--drop-dead_--force__96_____95__revives__95___repositories.mdwn b/doc/bugs/__96__git_annex_forget_--drop-dead_--force__96_____95__revives__95___repositories.mdwn
new file mode 100644
index 000000000..8cd8766ec
--- /dev/null
+++ b/doc/bugs/__96__git_annex_forget_--drop-dead_--force__96_____95__revives__95___repositories.mdwn
@@ -0,0 +1,86 @@
+As per topic, `git annex forget --drop-dead --force` does not behave as expected. Instead of getting rid of dead repositories, it actually revives them.
+
+I messed up the initial setup of the S3 special remote and instead of risking manual intervention, I figured it would be cleanest to nuke the old special remotes, using a new one instead.
+And yes, I should have used a test repo :(
+
+As this is apu.debconf.org, you could get access to the repo if that helps.
+
+
+[[!format sh """
+richih@apu (git)-[master] /srv/video/video.debian.net % git annex info
+repository mode: indirect
+trusted repositories: 0
+semitrusted repositories: 4
+	00000000-0000-0000-0000-000000000001 -- web
+ 	070cff8a-6302-4aa7-a63c-3fdd34e598a2 -- amazon_s3_us_east--SHA512E
+ 	0bae683f-bede-43dd-a815-c4f8fb6db32d -- aws_s3_us_east--SHA512E
+ 	92e9fac9-97ec-401f-a421-33f6b4f43e47 -- here (apu.debconf.org/srv/video/conference_videos.annex)
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 136.3 gigabytes (+1 megabyte reserved)
+local annex keys: 4392
+local annex size: 884.64 gigabytes
+annexed files in working tree: 4628
+size of annexed files in working tree: 885.68 gigabytes
+bloom filter size: 16 mebibytes (0.9% full)
+backend usage: 
+	SHA512E: 9020
+richih@apu (git)-[master] /srv/video/video.debian.net % git annex dead 070cff8a-6302-4aa7-a63c-3fdd34e598a2
+dead 070cff8a-6302-4aa7-a63c-3fdd34e598a2 ok
+(Recording state in git...)
+richih@apu (git)-[master] /srv/video/video.debian.net % git annex dead 0bae683f-bede-43dd-a815-c4f8fb6db32d
+dead 0bae683f-bede-43dd-a815-c4f8fb6db32d ok
+(Recording state in git...)
+richih@apu (git)-[master] /srv/video/video.debian.net % git annex initremote amazon_aws_s3-us_east_1--SHA512E type=S3 encryption='none' embedcreds='no' fileprefix='SHA512E/' bucket='debian-video'
+initremote amazon_aws_s3-us_east_1--SHA512E (checking bucket...) git-annex: This bucket is already in use by a different S3 special remote, with UUID: 0bae683f-bede-43dd-a815-c4f8fb6db32d
+richih@apu (git)-[master] /srv/video/video.debian.net % git annex info
+repository mode: indirect
+trusted repositories: 0
+semitrusted repositories: 2
+	00000000-0000-0000-0000-000000000001 -- web
+ 	92e9fac9-97ec-401f-a421-33f6b4f43e47 -- here (apu.debconf.org/srv/video/conference_videos.annex)
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 136.3 gigabytes (+1 megabyte reserved)
+local annex keys: 4392
+local annex size: 884.64 gigabytes
+annexed files in working tree: 4628
+size of annexed files in working tree: 885.68 gigabytes
+bloom filter size: 16 mebibytes (0.9% full)
+backend usage: 
+	SHA512E: 9020
+richih@apu (git)-[master] /srv/video/video.debian.net % git annex forget --drop-dead --force
+forget git-annex (Recording state in git...)
+ok
+(Recording state in git...)
+richih@apu (git)-[master] /srv/video/video.debian.net % git annex info
+repository mode: indirect
+trusted repositories: 0
+semitrusted repositories: 4
+	00000000-0000-0000-0000-000000000001 -- web
+ 	070cff8a-6302-4aa7-a63c-3fdd34e598a2 -- amazon_s3_us_east--SHA512E
+ 	0bae683f-bede-43dd-a815-c4f8fb6db32d -- aws_s3_us_east--SHA512E
+ 	92e9fac9-97ec-401f-a421-33f6b4f43e47 -- here (apu.debconf.org/srv/video/conference_videos.annex)
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 136.3 gigabytes (+1 megabyte reserved)
+local annex keys: 4392
+local annex size: 884.64 gigabytes
+annexed files in working tree: 4628
+size of annexed files in working tree: 885.68 gigabytes
+bloom filter size: 16 mebibytes (0.9% full)
+backend usage: 
+	SHA512E: 9020
+richih@apu (git)-[master] /srv/video/video.debian.net % git annex version
+git-annex version: 5.20140117~bpo70+2
+build flags: Assistant Webapp Pairing S3 Inotify DBus XMPP Feeds Quvi TDFA
+key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SHA256 SHA1 SHA512 SHA224 SHA384 WORM URL
+remote types: git gcrypt S3 bup directory rsync web tahoe glacier hook external
+local repository version: 5
+supported repository version: 5
+upgrade supported from repository versions: 0 1 2 4
+richih@apu (git)-[master] /srv/video/video.debian.net % cat /etc/issue
+Debian GNU/Linux 7 \n \l
+
+richih@apu (git)-[master] /srv/video/video.debian.net % 
+"""]]
diff --git a/doc/devblog/day_141__f-droid_sprint/comment_1_1cc76207020ac478747117c76d7b5f9c._comment b/doc/devblog/day_141__f-droid_sprint/comment_1_1cc76207020ac478747117c76d7b5f9c._comment
new file mode 100644
index 000000000..9971f33da
--- /dev/null
+++ b/doc/devblog/day_141__f-droid_sprint/comment_1_1cc76207020ac478747117c76d7b5f9c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmJuOOkYYguRbWhXzxihIPBavxITJIMyww"
+ nickname="Matt"
+ subject="Excellent News"
+ date="2014-03-26T14:14:35Z"
+ content="""
+It will be great to see git-annex on f-droid!
+"""]]
diff --git a/doc/forum/How_to_know_why_is_git-annex_uploading_a_file_to_a_transfer_repository.mdwn b/doc/forum/How_to_know_why_is_git-annex_uploading_a_file_to_a_transfer_repository.mdwn
new file mode 100644
index 000000000..48ad2d1d8
--- /dev/null
+++ b/doc/forum/How_to_know_why_is_git-annex_uploading_a_file_to_a_transfer_repository.mdwn
@@ -0,0 +1,3 @@
+I have git-annex set up with three clients and a transfer repository and everything was working fine, but a couple of days ago I noticed that git-annex was starting to upload to the transfer repository files that where already present on the three clients, and it hasn't stopped since. It's uploading all my files and I don't really know why.
+
+Is there a way to know why does git-annex think it needs to upload this files?
diff --git a/doc/todo/clear_file_names_in_special_remotes.mdwn b/doc/todo/clear_file_names_in_special_remotes.mdwn
new file mode 100644
index 000000000..149265038
--- /dev/null
+++ b/doc/todo/clear_file_names_in_special_remotes.mdwn
@@ -0,0 +1,9 @@
+To properly use amazon AWS S3 for CDN, we need to publish videos to S3. Ideally, we would like to do this via git-annex as the back-end of video.debian.net is being migrated to git-annex by me, atm.
+
+Obviously, we will need clear text names and proper directory structure, not SHA512E file names. This would need to be supported by the S3 special remote.
+
+I talked to TobiasTheViking in the past and he hinted at a reasonably clean way to do this, but that a clean solution would need support from git-annex. I will link him to this page and ask him to supply whatever info is needed.
+
+
+Thanks,
+Richard