| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This is a nice win; much less code runs in Annex, so other threads have
more chances to run concurrently.
I do notice that renaming a file has gone from 1 to 2 commits. I think this
is due to the above improvement letting the committer run more frequently,
so it commits the rm first.
|
| |
|
|
|
|
|
|
|
|
| |
Converted several threads to run in the monad.
Added a lot of useful combinators for working with the monad.
Now the monad includes the name of the thread.
Some debugging messages are disabled pending converting other threads.
|
| |
|
|
|
| |
This adds the Assistant monad, and an AssistantData structure.
So far, none of the assistant's threads run in the monad yet.
|
| |
|
|
| |
Will be used for finding other git-annex clients for pairing
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I now have this topology working:
assistant ---> {bare repo, special remote} <--- assistant
And, I think, also this one:
+----------- bare repo --------+
v v
assistant ---> special remote <--- assistant
While before with assistant <---> assistant connections, both sides got
location info updated after a transfer, in this topology, the bare repo
*might* get its location info updated, but the other assistant has no way to
know that it did. And a special remote doesn't record location info,
so transfers to it won't propigate out location log changes at all.
So, for these to work, after a transfer succeeds, the git-annex branch
needs to be pushed. This is done by recording a synthetic commit has
occurred, which lets the pusher handle pushing out the change (which will
include actually committing any still journalled changes to the git-annex
branch).
Of course, this means rather a lot more syncing action than happened
before. At least the pusher bundles together very close together pushes,
somewhat. Currently it just waits 2 seconds between each push.
|
| |
|
|
| |
Seems nothing else ensures the branch is committed anymore.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
I am befuddled that Twitter Bootstrap has no built-in Icon for The Cloud,
and also that Chromium's depiction of CLOUD (U+2601) has an uncanny
resemblance to PILE OF POO (U+1F4A9) when rendered small, and looks like a
looming Frankenstorm when rendered large, and not a sweet, sunny, nothing
can go wrong The Cloud.
<http://www.fileformat.info/info/unicode/char/2601/browsertest.htm>
So, I must resort to irony in my choice of icons.
|
| | |
|
| | |
|
| |
|
|
|
| |
If it managed to run for 5 minutes, reconnect immediately. Otherwise,
wait 5 minutes before reconnecting.
|
| |
|
|
|
|
|
|
| |
Adjust build deps to ensure that only a fixed version of the library will
be used.
Also, removed the bound thread stuff, which I now think was (probably)
a red herring.
|
| |\
| |
| |
| |
| | |
Conflicts:
Assistant/Threads/NetWatcher.hs
|
| | |
| |
| |
| |
| |
| |
| |
| | |
MountWatcher can't do this, because it uses the session dbus,
and won't have access to the new DBUS_SESSION_BUS_ADDRESS if a new session
is started.
Bumped dbus library version, FD leak in it is fixed.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
Currently relies on SRV being set, or the JID's hostname being the server
hostname and the port being default. Future work: Allow manual
configuration of user name, hostname, and port.
|
| | | |
|
| | | |
|
| |\|
| |
| |
| |
| |
| | |
Conflicts:
Assistant/Threads/MountWatcher.hs
Assistant/Threads/NetWatcher.hs
|
| | |
| |
| |
| |
| |
| |
| | |
Now when the dbus connection is dropped, it'll fall back to polling.
I could make it try to reconnect, but there's a FD leak in the dbus
library, so not yet.
|
| | |
| |
| |
| | |
which doesn't work with LDAP or NIS.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This *may* solve the segfault I was seeing when the XMPP library called
startTLS. My hypothesis is as follows:
* TLS is documented
(http://www.gnu.org/software/gnutls/manual/gnutls.html#Thread-safety)
thread safe, but only when a single thread accesses it.
* forkIO threads are not bound to an OS thread, so it was possible for
the threaded runtime to run part of the XMPP code on one thread, and
then switch to another thread later.
So, forkOS, with its bound threads, should be used for the XMPP thread.
Since the crash doesn't happen reliably, I am not yet sure about this fix.
Note that I kept all the other threads in the assistant unbound, because
bound threads have significantly higher overhead.
|
| | |
| |
| |
| |
| | |
When pushing to multiple UUIDs, combine them all into a single push
attribute.
|
| | |
| |
| |
| | |
Push notifications are actually working over XMPP now!
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Seems presence notifications are not sent to clients that have marked
themselves unavailable. (Testing with google talk.)
This is the death knell for the presence hack, because it has to stay
available, and even the toggle to unavailable and back could cause it to
miss a notification. Still, flipped it so it basically works, for now.
|
| | |
| |
| |
| |
| | |
Still need to do something about transfer queueing, however. This could be
a real can of worms.
|
| | |
| |
| |
| |
| |
| |
| | |
Lacking error handling, reconnection, credentials configuration,
and doesn't actually do anything when it receives an incoming notification.
Other than that, it might work! :)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Hooked up everything that needs to notify on pushes. Note that
syncNewRemote does not notify. This is probably ok, and I'd need to thread
more state through to make it do so.
This is only set up to support a single push notification method; I didn't
use a NotificationBroadcaster. Partly because I don't yet know what info
about pushes needs to be communicated, so my data types are only
preliminary.
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Monitors git-annex branch for changes, which are noticed by the Merger
thread whenever the branch ref is changed (either due to an incoming push,
or a local change), and refreshes cached config values for modified config
files.
Rate limited to run no more often than once per minute. This is important
because frequent git-annex branch changes happen when files are being
added, or transferred, etc.
A primary use case is that, when preferred content changes are made,
and get pushed to remotes, the remotes start honoring those settings.
Other use cases include propigating repository description and trust
changes to remotes, and learning when a remote has added a new special
remote, so the webapp can present the GUI to enable that special remote
locally.
Also added a uuid.log cache. All other config files already had caches.
|
| |
|
|
| |
Yay, monadic Either!
|
| |\
| |
| |
| |
| |
| | |
Conflicts:
debian/changelog
git-annex.cabal
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
This can result in the file being dropped, or being downloaded, or even
being dropped from some other repo.
It's even possible to create a file in a directory where content is not
wanted, which will make the assistant immediately send it elsewhere, and
then drop it.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This was complicated quite a bit by needing to check numcopies. I optimised
that, so it only looks up numcopies once per file, no matter how many
remotes it checks to drop from. Although it did just occur to me that
it might be better to first check if it wants to drop content, and only
then check numcopies..
|
| | |
| |
| |
| | |
Also a small optimisation using a Set
|
| | | |
|
| | | |
|
Joey Hess
Nicolas Pouillard