Merge branch 'master' into newchunks

6 files changed, 113 insertions, 1 deletions

diff --git a/Remote/Helper/Encryptable.hs b/Remote/Helper/Encryptable.hs
index a6e79ddc4..41174cf7c 100644
--- a/Remote/Helper/Encryptable.hs
+++ b/Remote/Helper/Encryptable.hs
@@ -87,7 +87,10 @@ encryptableRemote c storeKeyEncrypted retrieveKeyFileEncrypted r =
 		retrieveKeyFileCheap = retrieveCheap,
 		removeKey = withkey $ removeKey r,
 		hasKey = withkey $ hasKey r,
-		cost = cost r + encryptedRemoteCostAdj
+		cost = maybe
+			(cost r)
+			(const $ cost r + encryptedRemoteCostAdj)
+			(extractCipher c)
 	}
   where
 	store k f p = cip k >>= maybe
diff --git a/debian/changelog b/debian/changelog
index 5509b76e0..bbdea7b7b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -6,6 +6,7 @@ git-annex (5.20140718) UNRELEASED; urgency=medium
     unreachable objects, but some branches no longer accessible.
     Fix this, including support for fixing up repositories that
     were incompletely repaired before.
+  * Fix cost calculation for non-encrypted remotes.
 
  -- Joey Hess <joeyh@debian.org>  Mon, 21 Jul 2014 14:41:26 -0400
 
diff --git a/doc/bugs/Out_of_memory_error_in_fsck_whereis_find_and_status_cmds/comment_8_cf1f9d0be5da4ba874209d981ff8afc6._comment b/doc/bugs/Out_of_memory_error_in_fsck_whereis_find_and_status_cmds/comment_8_cf1f9d0be5da4ba874209d981ff8afc6._comment
new file mode 100644
index 000000000..976664a94
--- /dev/null
+++ b/doc/bugs/Out_of_memory_error_in_fsck_whereis_find_and_status_cmds/comment_8_cf1f9d0be5da4ba874209d981ff8afc6._comment
@@ -0,0 +1,38 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawlVUq_c3-lrQBculOEUu3yjvdavE7JbvEI"
+ nickname="Stig"
+ subject="comment 8"
+ date="2014-07-25T10:02:53Z"
+ content="""
+\"git annex sync\" or \"git annex fsck\" gives me the same problem.  This is an annex which has previously been running with the git annex assistant.
+
+Output is first:
+
+    $ git annex sync
+    (merging synced/git-annex into git-annex...)
+
+…then the workstation starts swapping, and after eating 16 GB RAM, and all of 16 GB swap, OOM killer komes for \"git\".
+
+The process which eats up all the memory is:
+
+    git --git-dir=/home/ssm/annex/.git --work-tree=/home/ssm/annex \
+      -c core.bare=false log \
+      7bed443dc22961214f86e65aedb8861affd215d3..refs/heads/git-annex \
+      -n1 --pretty=%H
+
+I _think_ that since a \"-n1\" argument is given, it will only show the log for the last commit in the range, and one could specify \"refs/heads/git-annex\" instead of the range.  With just \"refs/heads/git-annex\" instead of the range, it returns a reference instantly.
+
+The output of git count-objects is
+
+    $ git count-objects -H -v
+    count: 334758
+    size: 6.27 GiB
+    in-pack: 16600
+    packs: 1
+    size-pack: 1.70 MiB
+    prune-packable: 0
+    garbage: 0
+    size-garbage: 0 bytes
+
+…and there is 1043 files in the annex.
+"""]]
diff --git a/doc/bugs/youtube_web_download_gives_Prelude.undefined_in_webapp.mdwn b/doc/bugs/youtube_web_download_gives_Prelude.undefined_in_webapp.mdwn
new file mode 100644
index 000000000..7112818ed
--- /dev/null
+++ b/doc/bugs/youtube_web_download_gives_Prelude.undefined_in_webapp.mdwn
@@ -0,0 +1,25 @@
+### Please describe the problem.
+
+I'm downloading a video with 'git annex addurl' from youtube. The webapp shows the transfer, but when I click the 'web' link it takes me to a page that says "internal server error" and "Prelude.undefined"
+
+### What steps will reproduce the problem?
+
+1. start webapp
+2. download youtube video
+3. click 'web' link on transfer in git-annex
+
+### What version of git-annex are you using? On what operating system?
+
+* Version: 5.20140717
+* OS: Debian sid
+
+### Please provide any additional information below.
+
+Not much in the logs, I see this:
+
+[[!format sh """
+
+[2014-07-25 08:40:14 BST] TransferWatcher: transfer starting: Download UUID "00000000-0000-0000-0000-000000000001" URL--quvi:https://www.youtube.com/watch,63v,61Z8_8jNLsZms Nothing
+[2014-07-25 08:40:14 BST] TransferWatcher: transfer starting: Download UUID "00000000-0000-0000-0000-000000000001" Chase_Adam_at_Startup_School_NY_2014.mp4 Nothing
+
+"""]]
diff --git a/doc/devblog/day_203__in_the_weeds.mdwn b/doc/devblog/day_203__in_the_weeds.mdwn
new file mode 100644
index 000000000..a8cf1787a
--- /dev/null
+++ b/doc/devblog/day_203__in_the_weeds.mdwn
@@ -0,0 +1,39 @@
+A lil bit in the weeds on the chunking rewrite right now. I did succeed in
+writing the core chunk generation code, which can be used for every special
+remote. It was pretty hairy (needs to stream large files in constant
+memory, separating into chunks, and get the progress display right
+across operations on chunks, etc). That took most of the day.
+
+Ended up getting stuck in integrating the encryptable remote code, and had
+to revert changes that could have led to rewriting (or perhaps
+eliminating?) most of the per-remote encryption specific code.
+
+Up till now, this has supported both encrypted and non-encrypted remotes;
+it was simply passed encrypted keys for an encrypted remote:
+
+[[!format haskell """
+remove :: Key -> Annex Bool
+"""]]
+
+But with chunked encrypted keys, it seems it needs to be more complicated:
+
+[[!format haskell """
+remove' :: Maybe (Key -> Key) -> ChunkConfig -> Key -> Annex Bool
+"""]]
+
+So that when the remote is configured to use chunking, it can look up
+the chunk keys, and then encrypt them, in order to remove all the encrypted
+chunk keys.
+
+I don't like that complication, so want to find a cleaner
+abstraction. Will sleep on it.
+
+----
+
+While I was looking at the encryptable remote generator, I realized
+the remote cost was being calculated wrongly for special 
+remotes that are not encrypted. Fixed that bug.
+
+----
+
+Today's work was sponsored by bak.
diff --git a/doc/walkthrough/renaming_files.mdwn b/doc/walkthrough/renaming_files.mdwn
index 85964d1ea..7ae5f633c 100644
--- a/doc/walkthrough/renaming_files.mdwn
+++ b/doc/walkthrough/renaming_files.mdwn
@@ -11,3 +11,9 @@ Notice that, since annexed files are represented by symlinks,
 the symlink will break when the file is moved into a subdirectory.
 But, git-annex will fix this up for you when you commit --
 it has a pre-commit hook that watches for and corrects broken symlinks.
+
+## Direct mode
+
+Note that these git commands only work when git-annex is using indirect mode. Repositories created by the [[assistant]] are in [[direct_mode]]. Running 'git mv' in direct mode will give you an error:
+
+    fatal: This operation must be run in a work tree