7189dfd77d
* webapp: Detect when upgrades are available, and upgrade if the user
desires.
(Only when git-annex is installed using the prebuilt binaries
from git-annex upstream, not from eg Debian.)
* assistant: Detect when the git-annex binary is modified or replaced,
and either prompt the user to restart the program, or automatically
restart it.
* annex.autoupgrade configures both the above upgrade behaviors.
* Added support for quvi 0.9. Slightly suboptimal due to limitations in its
interface compared with the old version.
* Bug fix: annex.version did not get set on automatic upgrade to v5 direct
mode repo, so the upgrade was performed repeatedly, slowing commands down.
* webapp: Fix bug that broke switching between local repositories
that use the new guarded direct mode.
* Android: Fix stripping of the git-annex binary.
* Android: Make terminal app show git-annex version number.
* Android: Re-enable XMPP support.
* reinject: Allow to be used in direct mode.
* Futher improvements to git repo repair. Has now been tested in tens
of thousands of intentionally damaged repos, and successfully
repaired them all.
* Allow use of --unused in bare repository.
# imported from the archive
50 lines
2 KiB
Markdown
50 lines
2 KiB
Markdown
Random improvements day..
|
|
|
|
Got the merge conflict resolution code working in `git annex assistant`.
|
|
|
|
Did some more fixes to the pushing and pulling code, covering some cases
|
|
I missed earlier.
|
|
|
|
Git syncing seems to work well for me now; I've seen it recover
|
|
from a variety of error conditions, including merge conflicts and repos
|
|
that were temporarily unavailable.
|
|
|
|
----
|
|
|
|
There is definitely a MVar deadlock if the merger thread's inotify event
|
|
handler tries to run code in the Annex monad. Luckily, it doesn't
|
|
currently seem to need to do that, so I have put off debugging what's going
|
|
on there.
|
|
|
|
Reworked how the inotify thread runs, to avoid the two inotify threads
|
|
in the assistant now from both needing to wait for program termination,
|
|
in a possibly conflicting manner.
|
|
|
|
Hmm, that *seems* to have fixed the MVar deadlock problem.
|
|
|
|
----
|
|
|
|
Been thinking about how to fix [[bugs/watcher_commits_unlocked_files]].
|
|
Posted some thoughts there.
|
|
|
|
It's about time to move on to data [[syncing]]. While eventually that will
|
|
need to build a map of the repo network to efficiently sync data over the
|
|
fastest paths, I'm thinking that I'll first write a dumb version. So, two
|
|
more threads:
|
|
|
|
1. Uploads new data to every configured remote. Triggered by the watcher
|
|
thread when it adds content. Easy; just use a `TSet` of Keys to send.
|
|
|
|
2. Downloads new data from the cheapest remote that has it. Could be
|
|
triggered by the
|
|
merger thread, after it merges in a git sync. Rather hard; how does it
|
|
work out what new keys are in the tree without scanning it all? Scan
|
|
through the git history to find newly created files? Maybe the watcher
|
|
triggers this thread instead, when it sees a new symlink, without data,
|
|
appear.
|
|
|
|
Both threads will need to be able to be stopped, and restarted, as needed
|
|
to control the data transfer. And a lot of other control smarts will
|
|
eventually be needed, but my first pass will be to do a straightforward
|
|
implementation. Once it's done, the git annex assistant will be basically
|
|
usable.
|