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

This commit is contained in:
Joey Hess 2013-07-16 19:08:31 -04:00
commit 8805c12a90
9 changed files with 83 additions and 0 deletions

View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="4.154.4.90"
subject="comment 1"
date="2013-07-16T19:30:55Z"
content="""
That's not really how you're meant to use the standalone tarball. Just untar it somewhere, and add that directory to PATH (eg, in `~/.bash_profile`).
"""]]

View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawkF8_uQjLYm5Mf5F_JuVW-BxlvzpWjvR_o"
nickname="Andrew"
subject="git annex fsck"
date="2013-07-16T22:22:25Z"
content="""
Running git annex fsck appears to have resolved the corruption, but it removed all the content and the assistant hasn't refetched them.
I'm running git annex get . now to refetch all the content.
"""]]

View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://siancu.myopenid.com/"
nickname="siancu"
subject="comment 5"
date="2013-07-16T19:52:28Z"
content="""
Ok, I will try without XMPP. However I'm going to need it, because, if I understood correctly, it is needed to do remote pairings. But for now I can manage without as I can take the laptop with me to work and to syncing locally.
"""]]

View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="4.154.4.90"
subject="comment 2"
date="2013-07-16T19:08:49Z"
content="""
However, if you then run `git annex uninit` a second time, it goes ahead and deletes the content! That is a bug.
I looked into trying to make uninit always replace the symlink atomically with the file content. It can't be done when using --fast, since it's not possible to atomically replace a symlink with a hard link (AFAIK). It should be possible to do it in the normal mode, but it would require manually constructing a commit, since git does not provide a way to delete a file from the index and commit that staged change without also committing any other changes that are staged -- and uninit should preseve any changes to non-annexed files that the user has staged. So, I don't think atomic operation is the right answer.
Instead, I have made uninit refuse to delete .git/annex/objects unless it's empty, and if objects are still left in there, for whatever reason, it'll fail at the end with a nice message explaining some options. I think this is the right fix because it also avoids uninit removing historical versions of files that were stored in git-annex.g
"""]]

View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="4.154.4.90"
subject="comment 1"
date="2013-07-16T19:40:20Z"
content="""
Yes, you need to add the rsync remote to the second computer. Once it's set up, they will be able to exchange file contents using it, and using XMPP as a control channel.
If the first computer already has that rsync remote configured, it should push some notes about the existance of that remote to the second one, over XMPP. Then in the webapp, you should just need to click on \"enable\" next to the rsync remote, and it'll prompt for the necessary info to set it up.
"""]]

View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="4.154.4.90"
subject="comment 1"
date="2013-07-16T19:45:42Z"
content="""
git-annex stores a clone of the git repository on the removable drive. To encrypt a git remote, you can use the [git-remote-gcrypt](https://github.com/blake2-ppc/git-remote-gcrypt) tool. This will work with git-annex, but it needs integration into the webapp to support setting it up, and further integration so git-annex can detect when a git remote is encrypted and also encrypt the contents of file is stores there.
"""]]

View file

@ -0,0 +1,7 @@
This falls into the category of "noob questions" I think.
The one piece of the git-annex assistant puzzle I've never messed with is XMPP pairing. I'm wondering how well a pair of repos can keep in sync with each other if their only connection is via XMPP. Will things go badly if changes are made to one while the other is offline? Do messages get queued up to deliver when they're both online? (Or do they get queued on the server side so they can be delivered even if one of them is online, makes changes, then goes offline, and the other one comes online later?)
If some xmpp messages don't go through for whatever reason, will the remotes be able to "catch up" with each other later on and make up for lost time?
Just hoping for a general sense of the limitations of XMPP pairing. TIA.

View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="4.154.4.90"
subject="comment 1"
date="2013-07-16T19:27:07Z"
content="""
Both clients have to be online at the same time for XMPP push to work. Once they're able to see each other, they'll sync up, even if they've diverged since the last sync.
If you tend to only have one client or the other online, you should set up a git repo on a ssh server. Then clients will drop off their changes there, and the other one will check it when it comes online. (You don't really need to use XMPP at all in this case.)
The most robust and fast combo is to use XMPP pairing, and also have a git repo on a ssh server. This way, when both clients are online, they'll use XMPP to instantly propagate changes, and when not the server is there to fall back to.
"""]]

View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="4.154.4.90"
subject="comment 1"
date="2013-07-16T19:16:54Z"
content="""
There is already one example of a lossy remote: If you use `git annex addurl --relaxed` it generates a key that just uses the url, without its size. When retreiving such a key, any content will be accepted.
"""]]