diff options
4 files changed, 59 insertions, 0 deletions
diff --git a/doc/bugs/Photos___34__disappear__34___after_adding_a_remote_server_repository_on_Android.mdwn b/doc/bugs/Photos___34__disappear__34___after_adding_a_remote_server_repository_on_Android.mdwn new file mode 100644 index 000000000..4509ff8cc --- /dev/null +++ b/doc/bugs/Photos___34__disappear__34___after_adding_a_remote_server_repository_on_Android.mdwn @@ -0,0 +1,22 @@ +### Please describe the problem. + +I have a very simple use case for Git Annex on Android : I want my photos to be transferred to my home server automatically, in a special "incoming photos" folder, where they eventually get classified into other folders or deleted. git-annex in installed on this server. + +However, adding a Remote server (ssh) repository on a Photos repository on Android results in a totally confusing situation where the files on the Android device are removed and transferred to a bare repository on the server. Getting out of this sticky situation requires some commandline-fu. + +### What steps will reproduce the problem? + +1. Install git-annex on Android +2. Open git-annex from the apps menu +3. Accept offer to create a Photos repository +4. Add a "Remote server" server repository +5. Wait a bit. +6. "Uh oh." + +### What version of git-annex are you using? On what operating system? + +Using git-annex Android and Debian. + +### Please provide any additional information below. + +I thought that adding a remote server repository would result in two non-bare repositories, such as what the Local pairing mode achieves. However Local pairing is not available on Android. I assumed the remote server would function in the same manner, except that I entered the SSH connection information manually. diff --git a/doc/bugs/local_pair_fails_if_non-ascii_characters_present_on_annex_path.mdwn b/doc/bugs/local_pair_fails_if_non-ascii_characters_present_on_annex_path.mdwn new file mode 100644 index 000000000..aa03c3054 --- /dev/null +++ b/doc/bugs/local_pair_fails_if_non-ascii_characters_present_on_annex_path.mdwn @@ -0,0 +1,16 @@ +### Please describe the problem. + +When the annex directory has a non-ascii character (like a tilde) on its path, local pairing fails and a couple of instances of the following message appear on the log + +"illegal control characters in pairing message; ignoring" + +### What steps will reproduce the problem? + +* make a new annex repo named on /home/someone/Vídeos/blah/ (notice the i with a tilde) on two computers +* try to pair them + +### What version of git-annex are you using? On what operating system? + +git-annex version: 5.20141016-g26b38fd on Arch Linux + +git-annex version: 5.20140717 on Ubuntu 14.10 diff --git a/doc/bugs/main_repo_not_available_on_downloads.kitenet.net/comment_2_22f456996079c88865b67caca51dfed9._comment b/doc/bugs/main_repo_not_available_on_downloads.kitenet.net/comment_2_22f456996079c88865b67caca51dfed9._comment new file mode 100644 index 000000000..f155a33ca --- /dev/null +++ b/doc/bugs/main_repo_not_available_on_downloads.kitenet.net/comment_2_22f456996079c88865b67caca51dfed9._comment @@ -0,0 +1,9 @@ +[[!comment format=mdwn + username="anarcat" + subject="comment 2" + date="2014-11-11T21:16:02Z" + content=""" +huh! weird. i just made up those \"steps to reproduce\" from memory, as I cloned the repo a while ago. maybe i just forgot to sync it? + +sorry for the noise. +"""]] diff --git a/doc/todo/Slow_transfer_for_a_lot_of_small_files./comment_1_fa76bc744e30aaeed4a3b3e2fe3dd75e._comment b/doc/todo/Slow_transfer_for_a_lot_of_small_files./comment_1_fa76bc744e30aaeed4a3b3e2fe3dd75e._comment new file mode 100644 index 000000000..c877f9359 --- /dev/null +++ b/doc/todo/Slow_transfer_for_a_lot_of_small_files./comment_1_fa76bc744e30aaeed4a3b3e2fe3dd75e._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawnKT33H9qVVGJOybP00Zq2NZmNAyB65mic" + nickname="Lucas" + subject="comment 1" + date="2014-11-12T07:58:07Z" + content=""" +Opening multiple connections to a host can be preferable sometimes and it's unlikely to be an issue at all for the larger remotes like Google, Microsoft or S3. + +For example, the OneDrive provider spends a lot of time sitting around waiting for initialisation between uploads. Using, say 5 threads instead of 1 would allow it to continue doing things while it waits. + +Multiple connections can also vastly improve upload speeds for users with congested home internet connections. +"""]] |