Merge remote-tracking branch 'branchable/master'

doc/bugs/backend_version_upgrade_leaves_repo_unusable.mdwn

@@ -0,0 +1,28 @@
+foo is a local repo, bar is a bare remote.
+
+I upgraded foo's git-annex to 0.20110325 and upgraded a local repo backend to version 2. I then ran `git annex copy . --to bar` and checked the remote. This created WORM:SHA512--123123 files in annex/objects. Understandable but unwanted. So I upgraded git-annex on bar's machine, as well.
+
+    % git annex copy . --to bar
+    copy quux (checking bar) git-annex-shell: Repository version 1 is not supported. Upgrade this repository: git-annex upgrade (to bar)
+    git-annex-shell: Repository version 1 is not supported. Upgrade this repository: git-annex upgrade
+    rsync: connection unexpectedly closed (0 bytes received so far) [sender]
+    rsync error: error in rsync protocol data stream (code 12) at io.c(601) [sender=3.0.7]
+    
+      rsync failed -- run git annex again to resume file transfer
+    failed
+
+Running `git annex upgrade` on bar's machine I get:
+
+    % git annex upgrade
+    upgrade  (v1 to v2) (moving content...) git-annex: Prelude.read: no parse
+
+Again, bar is a bare repo.
+Running the copy job again, I am still getting the same error as above (as expected). Partial contents of annex/objects on bar:
+
+    [...]
+    SHA512:123
+    WORM:SHA512--234
+    [...]
+
+
+-- RichiH

doc/bugs/git-annex_directory_hashing_problems_on_osx.mdwn

@@ -30,6 +30,9 @@ this has somewhat confused git when it tries to stage/merge files, I didn't noti
 
 >>> If you copied `.git/` over, perhaps you got a git repo without
 >>> core.ignorecase set right for the filesystem it landed on?
+
+>>>> I usually git clone or do a fresh repository and pull things in, I was also unaware of this ignorecase setting as well.
+
 >>> 
 >>> Something like this might reproduce it:
 
@@ -51,6 +54,47 @@ this has somewhat confused git when it tries to stage/merge files, I didn't noti
 >>>> if it thought 3 distinct files had been committed.
 >>>> --[[Joey]]
 
+>>>>> Doing the above test on a HFS+ partition yields this
+
+<pre>
+## with ignorecase=false
+commit bb024c6fd7482b2d10f60ae899cb7a949aca1ad8
+Author: Jimmy Tang <jtang@exia>
+Date:   Sun Mar 27 18:40:24 2011 +0100
+
+    commit
+
+diff --git a/Foo/bar b/Foo/bar
+new file mode 100644
+index 0000000..e69de29
+diff --git a/fOo/bar b/fOo/bar
+new file mode 100644
+index 0000000..e69de29
+diff --git a/fOo/other b/fOo/other
+new file mode 100644
+index 0000000..e69de29
+diff --git a/foo/bar b/foo/bar
+new file mode 100644
+index 0000000..e69de29
+</pre>
+
+>>>>> and without changing ignorecase
+
+<pre>
+commit 909a089158ffb98f8e91f98905e2bfdc7234666f
+Author: Jimmy Tang <jtang@exia>
+Date:   Sun Mar 27 18:46:57 2011 +0100
+
+    commit
+
+diff --git a/Foo/bar b/Foo/bar
+new file mode 100644
+index 0000000..e69de29
+diff --git a/Foo/other b/Foo/other
+new file mode 100644
+index 0000000..e69de29
+</pre>
+
 Also I came across this when I accidentally annexed some files in the .git-annex directory and it cause git-annex/git to be very unhappy when i pulled the repo to somewhere else. It might be worth teaching git-annex to disallow annex'ing of files inside the .git-annex/.git directories.
 
 > There is a guard against `git annex add .git-annex/foo`, but it doesn't

doc/bugs/git-annex_has_issues_with_git_when_staging__47__commiting_logs.mdwn

@@ -14,3 +14,5 @@ For now it's just a bit of extra work for me when it does occur but it does not
 
 >>> I've never seen git refuse to commit staged files. There would have to
 >>> be some error message? --[[Joey]] 
+
+>>>> there were no error messages at all

doc/forum/batch_check_on_remote_when_using_copy.mdwn

@@ -0,0 +1,8 @@
+When I copy my local repository with SHA* to a remote repo with SHA*, every single file is checked by itself which seems rather inefficient. When my remote is accessed via ssh, git-annex opens a new connections for every check. If you are not using a ssh key or key agent, this gets tedious...
+
+For all locked files, either git's built-in mechanisms should be used or, if that's not possible, a few hundred checksums (assuming SHA* backend) should be transfered at once and then checked locally before deciding that to transfer.
+
+Once all checks are done, one single transfer session should be started. Creating new sessions and waiting for TCP's slowstart to get going is a lot less than efficient.
+
+
+-- RichiH