b6d46c212e
* unannex, uninit: Avoid committing after every file is unannexed,
for massive speedup.
* --notify-finish switch will cause desktop notifications after each
file upload/download/drop completes
(using the dbus Desktop Notifications Specification)
* --notify-start switch will show desktop notifications when each
file upload/download starts.
* webapp: Automatically install Nautilus integration scripts
to get and drop files.
* tahoe: Pass -d parameter before subcommand; putting it after
the subcommand no longer works with tahoe-lafs version 1.10.
(Thanks, Alberto Berti)
* forget --drop-dead: Avoid removing the dead remote from the trust.log,
so that if git remotes for it still exist anywhere, git annex info
will still know it's dead and not show it.
* git-annex-shell: Make configlist automatically initialize
a remote git repository, as long as a git-annex branch has
been pushed to it, to simplify setup of remote git repositories,
including via gitolite.
* add --include-dotfiles: New option, perhaps useful for backups.
* Version 5.20140227 broke creation of glacier repositories,
not including the datacenter and vault in their configuration.
This bug is fixed, but glacier repositories set up with the broken
version of git-annex need to have the datacenter and vault set
in order to be usable. This can be done using git annex enableremote
to add the missing settings. For details, see
http://git-annex.branchable.com/bugs/problems_with_glacier/
* Added required content configuration.
* assistant: Improve ssh authorized keys line generated in local pairing
or for a remote ssh server to set environment variables in an
alternative way that works with the non-POSIX fish shell, as well
as POSIX shells.
# imported from the archive
52 lines
2 KiB
Markdown
52 lines
2 KiB
Markdown
The assistant should support upgrading itself.
|
|
|
|
## non-distro upgrades
|
|
|
|
When git-annex was installed from this website, the assistant should poll
|
|
periodically (once a day or so) to see if there is a new version.
|
|
It downloads, over https, a .info file, which contains a serialized data
|
|
type containing upgrade information. The url it's downloaded from is
|
|
configured by setting `UPGRADE_LOCATION` when building git-annex on the
|
|
autobuilders.
|
|
|
|
When a new version is found, the webapp prompts the user to start the
|
|
upgrade. (annex.autoupgrade can be set to true to upgrade w/o prompting.)
|
|
|
|
The upgrade process is automatic, and rather tricky. The file is downloaded
|
|
using git-annex (as a regular key!), and is then unpacked into a new
|
|
directory, and the programfile updated to point to it. Then git-annex
|
|
restarts itself.
|
|
|
|
### manifest files
|
|
|
|
To clean up the old installation, a git-annex.MANIFEST file is looked for
|
|
in it, and the files listed, as well as empty directories, are deleted.
|
|
I don't want to accidentially delete something I didn't ship!
|
|
|
|
## restart on upgrade
|
|
|
|
When git-annex is installed from a proper distribution package, there is no
|
|
need for the above. But, the assistant still needs to notice when git-annex
|
|
get upgraded, and offer to restart (or automatically restart when
|
|
annex.autoupgrade is set).
|
|
|
|
This is done using the DirWatcher, watching the directory containing the
|
|
git-annex binary. Or, in the case of a non-distro install, watching the
|
|
directory where eg git-annex.linux/ was unpacked.
|
|
|
|
When an change is detected, restart.
|
|
|
|
## multi-daemon upgrades
|
|
|
|
A single system may have multiple assistant daemons running in different
|
|
repositories.
|
|
|
|
In this case, one daemon should do the non-distro upgrade, and the rest
|
|
should notice the upgrade and restart.
|
|
|
|
I don't want every daemon trying to download the file at once..
|
|
|
|
Approach: The first new version is installed into a stable directory, based
|
|
on its version. So, start the upgrade by making this directory. If upgrade
|
|
is already in progress, the directory will already exist. (Remove directory
|
|
if upgrade fails.)
|