mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

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

Browse source
This commit is contained in:
Joey Hess 2013-05-22 13:10:16 -04:00
commit c1e10d2241
11 changed files with 194 additions and 10 deletions
Download patch file Download diff file Expand all files Collapse all files

8
doc/Android/comment_7_a56628a622da752806c42c5b8b54ceef._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawkwjBDXkP9HAQKhjTgThGOxUa1B99y_WRA"
nickname="Franck"
subject="Link issue"
date="2013-05-22T12:01:38Z"
content="""
Hi, I have exactly the same problem with the link that fails on my phone. However, I checked the permissions and they are as you describe on your tablet (except for the app number). At the same time, everything is fine on my tablet... The phone runs an old Cyanogenmod 7.2.0 (Android 2.3.7) while the tablet is a more recent Asus TF700T (Android 4.1.1). Let me know if you want me to run tests.
"""]]

84
doc/bugs/Manual_content_mode_isn__39__t_manual.mdwn Normal file
View file

@ -0,0 +1,84 @@
### Please describe the problem.
The `manual` content mode doesn't follow the description provided in the help page, instead it seems to collect content.
### What steps will reproduce the problem?
1. Create a new git annex repository using the webapp, set the content type to `client`.
2. Create another repository, and set the content type to `manual`.
3. Copy something into the `client` repository.
4. It will be pushed/pulled into the `manual` repository.
### What version of git-annex are you using? On what operating system?
git-annex version: 4.20130521-g25dba9d
Ubuntu 13.04 x64.
### Please provide any additional information below.
I have also noticed very weird behaviour that I have been unable to replicate in testing, but I will describe the setup that it currently happens in:
I have 3x repositories, one a `client` repository, and the other two are set to `manual`. When put a new file into the `client` repository, it is pushed onto the two `manual` repositories. When these repositories have received it, the client drops the file and re-downloads it from one of the `manual` repositories. Once it's been pushed, deleted, and pulled, everything is happy... but the extra step makes no difference.
[[!format sh """
[2013-05-22 20:41:44 EST] main: starting assistant version 4.20130521-g25dba9d
[2013-05-22 20:41:44 EST] TransferScanner: Syncing with test3, test2
Already up-to-date.
(scanning...) [2013-05-22 20:41:44 EST] Watcher: Performing startup scan
Already up-to-date.
Already up-to-date.
(started...) From /home/valorin/workspace/tmp/test3
f285dc2..406c20c git-annex -> test3/git-annex
cdf2ad3..508983c master -> test3/master
From /home/valorin/workspace/tmp/test2
1e04829..1c03533 git-annex -> test2/git-annex
8ad4bd3..18a5408 master -> test2/master
Updating 508983c..18a5408
Fast-forward
Already up-to-date.
To /home/valorin/workspace/tmp/test2
4e49293..a66ce5d git-annex -> synced/git-annex
508983c..18a5408 master -> synced/master
To /home/valorin/workspace/tmp/test3
4e49293..a66ce5d git-annex -> synced/git-annex
508983c..18a5408 master -> synced/master
Already up-to-date.
Already up-to-date.
[2013-05-22 20:42:07 EST] Committer: Adding Firefly S..acked.m4v
(merging test3/git-annex into git-annex...)
(merging test2/git-annex into git-annex...)
(Recording state in git...)
add Firefly S01E03 Bushwhacked.m4v (checksum...) [2013-05-22 20:42:15 EST] Committer: Committing changes to git
[2013-05-22 20:42:15 EST] Pusher: Syncing with test3, test2
Already up-to-date.
To /home/valorin/workspace/tmp/test2
a66ce5d..a6773dd git-annex -> synced/git-annex
18a5408..f9e7692 master -> synced/master
To /home/valorin/workspace/tmp/test3
a66ce5d..a6773dd git-annex -> synced/git-annex
18a5408..f9e7692 master -> synced/master
Already up-to-date.
Already up-to-date.
[2013-05-22 20:42:26 EST] Transferrer: Uploaded Firefly S..acked.m4v
[2013-05-22 20:42:26 EST] Pusher: Syncing with test3, test2
To /home/valorin/workspace/tmp/test3
a6773dd..c35f992 git-annex -> synced/git-annex
To /home/valorin/workspace/tmp/test2
a6773dd..c35f992 git-annex -> synced/git-annex
[2013-05-22 20:42:35 EST] Transferrer: Uploaded Firefly S..acked.m4v
[2013-05-22 20:42:35 EST] Pusher: Syncing with test3, test2
To /home/valorin/workspace/tmp/test3
c35f992..9e47813 git-annex -> synced/git-annex
To /home/valorin/workspace/tmp/test2
c35f992..9e47813 git-annex -> synced/git-annex
[2013-05-22 20:42:44 EST] Pusher: Syncing with test3, test2
Everything up-to-date
Everything up-to-date
"""]]

11
doc/bugs/adding_an_rsync.net_repo_give_an_gpg_error/comment_2_24dd024ac4b21a82a781343b8fe3891e._comment Normal file
View file

@ -0,0 +1,11 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawnmvJtM53ZX9h8OGQoU2t2OfGwrF7rxFX0"
nickname="Shawn"
subject="fixed"
date="2013-05-22T14:37:05Z"
content="""
seems to be fix with 4.20130521-g25dba9d.
Thanks
"""]]

6
doc/design/assistant/blog/day_270__release_and_xmpp.mdwn
View file

@ -18,12 +18,12 @@ queuing other messages, seems to be just wrong. This is code I wrote in the
fall, and have basically not touched since. And it shows. Spent 4 hours
this morning rewriting it. Went all Erlang and implemented message inboxes
using STM. I'm much more confident it won't drop messages on the
floor, which the old code certianly did do sometimes.
floor, which the old code certainly did do sometimes.
Added a check to avoid unncessary pushes over XMPP. Unfortunately, this
Added a check to avoid unnecessary pushes over XMPP. Unfortunately, this
required changing the protocol in a way that will make previous versions of
git-annex refuse to accept any pushes advertised by this version. Could not
find a way around that, but there were so many unncessary pushes happening
find a way around that, but there were so many unnecessary pushes happening
(and possibly contributing to other problems) that it seemed worth the
upgrade pain.

23
doc/forum/special_remote_for_IMAP/comment_3_27e3b644df6942ce4c103236d0d5cb1b._comment Normal file
View file

@ -0,0 +1,23 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawmWg4VvDTer9f49Y3z-R0AH16P4d1ygotA"
nickname="Tobias"
subject="comment 3"
date="2013-05-22T09:53:47Z"
content="""
I had to change the checkpresent hook to:
hogneygmail-checkpresent-hook = (imaputils.pl --subject $ANNEX_KEY --count | grep -q \\"1 messages\\" -) && echo $ANNEX_KEY || exit 0
Also, i have 5 files more than 30MB in size, that refuse to transfer.
postdrop: warning: uid=1001: File too large
sendmail: fatal: tou(1001): message file too big
Error sending message, child exited 75 (Deferred.).
Could not send the message.
store hook exited nonzero!
failed
This really needs some split operations to support large files.
"""]]

10
doc/special_remotes/comment_12_13237170ef5b6646e0e25d3421af3fe5._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://yarikoptic.myopenid.com/"
nickname="site-myopenid"
subject="How to establish local preference for (special) remotes"
date="2013-05-22T14:06:48Z"
content="""
Sorry if it is RTFM... If I have multiple original (reachable) remotes, how could I establish my preference for which one to be used in any given location?
usecase: if I clone a repository within amazon cloud instance -- I would now prefer if this (or all -- user-wide configuration somehow?) repository 'get's load from URLs originating in the cloud of this zone (e.g. having us-east-1.s3.amazonaws.com/ in their URLs).
"""]]

12
doc/special_remotes/comment_13_1a36a0483a9db04d36e0234a192ebad8._comment Normal file
View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawmkBwMWvNKZZCge_YqobCSILPMeK6xbFw8"
nickname="develop"
subject="Remote costs"
date="2013-05-22T14:15:03Z"
content="""
This should be implemented with costs
I refer you too: http://git-annex.branchable.com/design/assistant/blog/day_213__costs/
This has been implemented in the assistant, so if you use that, changing priority should be as simple as changing the order of the remotes on the web interface. Whichever remote is highest on the list, is the one your client will fetch from.
"""]]

8
doc/special_remotes/comment_14_a8419963dc024b1d9eb73807596012dc._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joeyh.name/"
nickname="joey"
subject="comment 14"
date="2013-05-22T14:30:00Z"
content="""
You do not need to use the assistant to configure the costs of remotes. Just set `remote.<name>.annex-cost` to appropriate values. See also the documentation for the `remote.<name>.annex-cost-command` which allows your own code to calculate costs.
"""]]

9
doc/tips/megaannex.mdwn
View file

@ -24,16 +24,11 @@ Run the program once to make an empty config file.
cd ~/megaannex; python2 megaannex.py
Edit the megaannex.conf file. Add your mega.co.nz username and password
Note: The folder option in the megaannex.conf file isn't yet used.
Edit the megaannex.conf file. Add your mega.co.nz username, password, and folder name.
## Configuring git-annex
git config annex.mega-store-hook 'python2 ~/megaannex/megaannex.py store --subject $ANNEX_KEY --file $ANNEX_FILE'
git config annex.mega-retrieve-hook 'python2 ~/megaannex/megaannex.py getfile --subject $ANNEX_KEY --file $ANNEX_FILE'
git config annex.mega-checkpresent-hook 'python2 ~/megaannex/megaannex.py fileexists --subject $ANNEX_KEY'
git config annex.mega-remove-hook 'python2 ~/megaannex/megaannex.py delete --subject $ANNEX_KEY'
git config annex.mega-hook '/usr/bin/python2 ~/megaannex/megaannex.py'
git annex initremote mega type=hook hooktype=mega encryption=shared
git annex describe mega "the mega.co.nz library"

13
doc/todo/support_for_writing_external_special_remotes.mdwn Normal file
View file

@ -0,0 +1,13 @@
It would be good to have something in between the hook special remote and the built-in special remotes.
The hook is easy to set up, but its simple interface misses some features that a more full-features interface could provide to a third-party program that wants to provide the best possible special remote it can w/o being written in haskell:
* No way to send progress updates when uploading, so no progress bars for uploads from hook special remotes in the webapp.
* No way to verify the `initremote` parameters include all needed configuration, and do any initalization needed.
* No way to query and/or set the remote.log while it's running. (Well, technically, `git annex enableremote` can set values..)
* No way to store per-key information to the git-annex branch.
These features could be added to git-annex as subcommands. Which would improve the general programmability and flexability of git-annex. OTOH, running `git-annex upload-progress` repeatedly is pretty ugly. Or the interface could provide a channel for the program and git-annex to communicate back and forth on. Maybe a mix of the two?
A final feature such an interface should provide is the ability to drop a program into PATH and have it just work, without the user needing to do any configuration beyond `initremote`. So, `git annex initremote foo type=$bar` should look for `git-annex-remote-$bar` in PATH if that's not a built-in special remote name.
--[[Joey]]

20
doc/todo/wishlist:_Advanced_settings_for_xmpp_and_webdav/comment_1_11c7444ab4988c60732af505b52bde3c._comment Normal file
View file

@ -0,0 +1,20 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawmWg4VvDTer9f49Y3z-R0AH16P4d1ygotA"
nickname="Tobias"
subject="Hooks too"
date="2013-05-22T10:40:33Z"
content="""
It would actually be very nice if this could be done with hooks too.
Especially with the new hook method.
Take this hook
mega-hook = /usr/bin/python2 ~/sources/megaannex/megaannex.py
git-annex could make a request with either the parameter(or environment variable) \"getsettingsobject\" that could return. {\"username\": \"\", \"password\": \"\", \"folder\": \"\"}.
The point being git-annex can request from the hooks program what settings it takes, and give a web interface to set it. Then store the information in the creds folder(ew ew, that folder is unencrypted, oh well) and pass it to the hook on run.
The advantage being that users wouldn't have to edit a settings file manually (this is currently also the case for the IMAP special remote, which also requires a settings file).
"""]]