Comments in the moderation queue:
Recent comments posted to this site:
and I would still maintain my view that removing intermediate directory withing .git/annex/objects whose current roles is simply to provide read-only protection might half the burden on the underlying file system, either annex repo(s) are multitude or a single one . lean view  could also be of good use as well. Similar exercises with simulated annex'es with >5M files also "helped" to identify problems with ZOL (ZFS on Linux) caching suggesting that even mere handling of such vast arrays of tiny files (as dead symlinks) might give filesystems a good test, so the leaner impact would be -- the better.
 e.g. https://github.com/datalad/datalad/issues/32#issuecomment-70523036
You cannot use a UUID like that. How is git-anndx supposed to know where
that UUID is, or how to access it?
You do not use git-annex initremote with normal git remotes, only special
Set up a git remote, and use git-annex get --from with that.
git-annex get --from
git remote add ssh://someplace/path/to/repo
git-annex will then figure out that that git remote is the one with that
UUID, and be able to use it.
Names of git remotes are completely separate from descriptions of
git-annex repositories, which is what git-annex info displays.
AFAIK, all the documentation is clear about the several things that you
seem to have gotten confused about. Pointers to any places in
the documentation that are confusing about these matters are appreciated..
It easy to setup. And it seems like as good a "canned" solution as box.net or whatever. I don't know if I would use it for sensitive stuff, but for a couple of repos, it makes sense to use it.
There seems to be some support for creating new projects (which I assume is repos) here.
What I'm seeing is the unicode arrow is replaced with 0092 and the elipsis
with &. It's losing the other byte.
The problem seems to be in the base64 encoding that's done, when the metadata
value contains spaces or a few other problem characters. These same
unicode characters roundtrip through without a problem when not embedded
in a string with spaces.
*Utility.Base64> let s = "…"
*Utility.Base64> (s, fromB64 $ toB64 s)
git-annex also uses base64 for encoding some creds
(and for tagged pushes over XMPP, but only the JID is encoded).
The real culprit is the use of w82s, which doesn't handle multi-byte
characters. I can easily fix this by using encodeW8 instead.
Audited git-annex for other problem w82s uses and don't see any, so will
only need to fix this once.
Added a quickcheck test for fromB64 . toB64 roundtripping.
Unfortunately, the entered unicode characters didn't get saved right,
so git-annex can do nothing to fix data that was already entered.
This uses ssh, so the repository address can be pasted into the webapp
as a ssh server, and it should work already.
It probably does make sense to add gitlab.com as a canned solution alongside
box.com and rsync.net in the webapp.
Since the remote will be a full git repository, it should prompt the user
if they want to enable gcrypt to encrypt all the content client-side.
If gitlab has a reasonable API for creating a new repository, the webapp
could optionally use that, instead of needing the user to create one
Ooops, the formatting got all messed up. Here it is again:
I am confused by the differences in the time between updates of different
repositories in the same machines and of the same repository in different
machines. I am using the assistant (in all machines,
'git annex assitant --autostart').
For instance, I have three machines synced as
A <-> B <-> C
and I have two directories being synced. The configuration (except for
directory names) is the same and looks like
uuid = something
version = 5
direct = true
autoupgrade = true
autocommit = true
startupscan = true
url = ssh://xxxxxx/~/repo/
fetch = +refs/heads/*:refs/remotes/machine_repo/*
annex-uuid = xxxxxxxxxxxxx
I modify or add a file in one of the directories in A, and it quickly
(less than 30 seconds) appears in B and shortly after that in C.
In another directory, however, more than 30 minutes can go by without C
ever changing (even if B gets the change almost immediately). Looking at
the logs I cannot understand what is happening. This is the case of a
file, A_sentinel_file_A, created at 01:46.
In B (where it appears almost immediately) I can see
[2015-03-02 01:46:17 CET] Pusher: Syncing with 123.456.789.101_somedir
794df9f..ae8c3f0 git-annex -> synced/git-annex
Automatic merge went well; stopped before committing as requested
[2015-03-02 01:47:03 CET] Committer: Committing changes to git
[2015-03-02 01:47:03 CET] Pusher: Syncing with 123.456.789.101_somedir
18 100% 0.00kB/s 0:00:00 (xfr#1, to-chk=0/1)
[2015-03-02 01:47:04 CET] Transferrer: Uploaded A_sentinel_file_A
ae8c3f0..b043335 git-annex -> synced/git-annex
75269bc..b61c7a5 annex/direct/master -> synced/master
[2015-03-02 01:47:04 CET] Committer: Committing changes to git
[2015-03-02 01:47:06 CET] Pusher: Syncing with 123.456.789.101_somedir
b043335..fc9279c git-annex -> synced/git-annex
And in C (the machine with IP 123.456.789.101, above) I can see
[2015-03-02 01:46:13 CET] RemoteControl: Syncing with Machine_B_somedir
593d908..794df9f git-annex -> Machine_B_somedir/git-annex
593d908..235149d synced/git-annex -> Machine_B_somedir/synced/git-annex
a1596b3..75269bc synced/master -> Machine_B_somedir/synced/master
[2015-03-02 01:46:17 CET] RemoteControl: Syncing with Machine_B_somedir
a1596b3..75269bc annex/direct/master -> Machine_B_somedir/annex/direct/master
794df9f..ae8c3f0 git-annex -> Machine_B_somedir/git-annex
a1596b3..75269bc master -> Machine_B_somedir/master
[2015-03-02 01:46:27 CET] RemoteControl: Syncing with Machine_B_somedir
ae8c3f0..632caa4 git-annex -> Machine_B_somedir/git-annex
235149d..632caa4 synced/git-annex -> Machine_B_somedir/synced/git-annex
[2015-03-02 01:47:02 CET] RemoteControl: Syncing with Machine_B_somedir
632caa4..56ac968 synced/git-annex -> Machine_B_somedir/synced/git-annex
75269bc..b61c7a5 synced/master -> Machine_B_somedir/synced/master
[2015-03-02 01:47:02 CET] RemoteControl: Syncing with Machine_B_somedir
632caa4..b043335 git-annex -> Machine_B_somedir/git-annex
[2015-03-02 01:47:07 CET] RemoteControl: Syncing with Machine_B_somedir
75269bc..b61c7a5 annex/direct/master -> Machine_B_somedir/annex/direct/master
b043335..fc9279c git-annex -> Machine_B_somedir/git-annex
75269bc..b61c7a5 master -> Machine_B_somedir/master
[2015-03-02 01:47:15 CET] RemoteControl: Syncing with Machine_B_somedir
fc9279c..a4642a8 git-annex -> Machine_B_somedir/git-annex
56ac968..a4642a8 synced/git-annex -> Machine_B_somedir/synced/git-annex
(merging synced/git-annex Machine_B_somedir/git-annex into git-annex...)
(recording state in git...)
[2015-03-02 02:17:23 CET] RemoteControl: Syncing with Machine_B_somedir
a4642a8..bfaba72 git-annex -> Machine_B_somedir/git-annex
a4642a8..bfaba72 synced/git-annex -> Machine_B_somedir/synced/git-annex
b61c7a5..29ff91e synced/master -> Machine_B_somedir/synced/master
Why did Machine C did not show the updated file at 01:47, which is when, I
think, machine B pushes it there? Or at 02:17 when both machines again
seem to talk to each other? Regardless, at 02:27 the file still was not
there. Yes, of course, if I issue a
git annex sync --content
then the file is shown in Machine C. But I should not need to do that.
In contrast, as I said, there is another directory, with identical
configuration, where these things do not happen and changes show
immediately (both directories, for now, only have tiny test files).
But is there a way to have the changes in one node (the "read only") discarded when there are changes in the remote, so that the new version in the remote is propagated to the read only node?
So I guess what I'd like is something like update-changes-from-others.sh (Like sync, but don't commit any local changes. Merge them like sync, don't discard) but without the merging, so discarding any changes as soon as a new version appears in the remote.
I've tried the remote.foo.annex-readonly = true in Android but I am not getting my intended behavior.
remote.foo.annex-readonly = true
For instance, suppose a computer and a Android device (but with direct mode, since working with assistant)
Adding autocommit = false does not help either.
autocommit = false