151 lines
7.5 KiB
Markdown
151 lines
7.5 KiB
Markdown
## version 3.20121126
|
|
|
|
This adds several features to the git-annex assistant, which is still in beta.
|
|
|
|
In general, anything you can configure with the assistant's web app
|
|
will work. Some examples of use cases supported by this release include:
|
|
|
|
* Using Box.com's 5 gigabytes of free storage space as a cloud transfer
|
|
point between between repositories that cannot directly contact
|
|
one-another. (Many other cloud providers are also supported, from Rsync.net
|
|
to Amazon S3, to your own ssh server.)
|
|
* Archiving or backing up files to Amazon Glacier.
|
|
* [[Sharing repositories with friends|share_with_a_friend_walkthrough]]
|
|
contacted through a Jabber server (such as Google Talk).
|
|
* [[Pairing|pairing_walkthrough]] two computers that are on the same local
|
|
network (or VPN) and automatically keeping the files in the annex in
|
|
sync as changes are made to them.
|
|
* Cloning your repository to removable drives, USB keys, etc. The assistant
|
|
will notice when the drive is mounted and keep it in sync.
|
|
Such a drive can be stored as an offline backup, or transported between
|
|
computers to keep them in sync.
|
|
|
|
The following are known limitations of this release of the git-annex
|
|
assistant:
|
|
|
|
* The Max OSX standalone app does not work on all versions of Max OSX.
|
|
* On Mac OSX and BSD operating systems, the assistant uses kqueue to watch
|
|
files. Kqueue has to open every directory it watches, so too many
|
|
directories will run it out of the max number of open files (typically
|
|
1024), and fail. See [[bugs/Issue_on_OSX_with_some_system_limits]]
|
|
for a workaround.
|
|
* Retrieval of files from Amazon Glacier is not fully automated; the
|
|
assistant does not automatically retry in the 4 to 5 hours period
|
|
when Glacier makes the files available.
|
|
|
|
## version 3.20121112
|
|
|
|
This is a major upgrade of the git-annex assistant, which is still in beta.
|
|
|
|
In general, anything you can configure with the assistant's web app
|
|
will work. Some examples of use cases supported by this release include:
|
|
|
|
* [[Sharing repositories with friends|share_with_a_friend_walkthrough]]
|
|
contacted through a Jabber server (such as Google Talk).
|
|
* Setting up cloud repositories, that are used as backups, archives,
|
|
or transfer points between repositories that cannot directly contact
|
|
one-another.
|
|
* [[Pairing|pairing_walkthrough]] two computers that are on the same local
|
|
network (or VPN) and automatically keeping the files in the annex in
|
|
sync as changes are made to them.
|
|
* Cloning your repository to removable drives, USB keys, etc. The assistant
|
|
will notice when the drive is mounted and keep it in sync.
|
|
Such a drive can be stored as an offline backup, or transported between
|
|
computers to keep them in sync.
|
|
|
|
The following upgrade notes apply if you're upgrading from a previous version:
|
|
|
|
* For best results, edit the configuration of repositories you set
|
|
up with older versions, and place them in a repository group.
|
|
This lets the assistant know how you want to use the repository; for backup,
|
|
archival, as a transfer point for clients, etc. Go to Configuration ->
|
|
Manage Repositories, and click in the "configure" link to edit a repository's
|
|
configuration.
|
|
* If you set up a cloud repository with an older version, and have multiple
|
|
clients using it, you are recommended to configure an Jabber account,
|
|
so that clients can use it to communicate when sending data to the
|
|
cloud repository. Configure Jabber by opening the webapp, and going to
|
|
Configuration -> Configure jabber account
|
|
* When setting up local pairing, the assistant did not limit the paired
|
|
computer to accessing a single git repository. This new version does,
|
|
by setting GIT_ANNEX_SHELL_DIRECTORY in `~/.ssh/authorized_keys`.
|
|
|
|
The following are known limitations of this release of the git-annex
|
|
assistant:
|
|
|
|
* On Mac OSX and BSD operating systems, the assistant uses kqueue to watch
|
|
files. Kqueue has to open every directory it watches, so too many
|
|
directories will run it out of the max number of open files (typically
|
|
1024), and fail. See [[bugs/Issue_on_OSX_with_some_system_limits]]
|
|
for a workaround.
|
|
|
|
## version 3.20121009
|
|
|
|
This is a maintenance release of the git-annex assistant, which is still in
|
|
beta.
|
|
|
|
In general, anything you can configure with the assistant's web app
|
|
will work. Some examples of use cases supported by this release include:
|
|
|
|
* [[Pairing|pairing_walkthrough]] two computers that are on the same local
|
|
network (or VPN) and automatically keeping the files in the annex in
|
|
sync as changes are made to them.
|
|
* Cloning your repository to removable drives, USB keys, etc. The assistant
|
|
will notice when the drive is mounted and keep it in sync.
|
|
Such a drive can be stored as an offline backup, or transported between
|
|
computers to keep them in sync.
|
|
* Cloning your repository to a remote server, running ssh, and uploading
|
|
changes made to your files to the server. There is special support
|
|
for using the rsync.net cloud provider this way, or any shell account
|
|
on a typical unix server, such as a Linode VPS can be used.
|
|
|
|
The following are known limitations of this release of the git-annex
|
|
assistant:
|
|
|
|
* On Mac OSX and BSD operating systems, the assistant uses kqueue to watch
|
|
files. Kqueue has to open every directory it watches, so too many
|
|
directories will run it out of the max number of open files (typically
|
|
1024), and fail. See [[bugs/Issue_on_OSX_with_some_system_limits]]
|
|
for a workaround.
|
|
* In order to ensure that all multiple repositories are kept in sync,
|
|
each computer with a repository must be running the git-annex assistant.
|
|
* The assistant does not yet always manage to keep repositories in sync
|
|
when some are hidden from others behind firewalls.
|
|
|
|
## version 3.20120924
|
|
|
|
This is the first beta release of the git-annex assistant.
|
|
|
|
In general, anything you can configure with the assistant's web app
|
|
will work. Some examples of use cases supported by this release include:
|
|
|
|
* [[Pairing|pairing_walkthrough]] two computers that are on the same local
|
|
network (or VPN) and automatically keeping the files in the annex in
|
|
sync as changes are made to them.
|
|
* Cloning your repository to removable drives, USB keys, etc. The assistant
|
|
will notice when the drive is mounted and keep it in sync.
|
|
Such a drive can be stored as an offline backup, or transported between
|
|
computers to keep them in sync.
|
|
* Cloning your repository to a remote server, running ssh, and uploading
|
|
changes made to your files to the server. There is special support
|
|
for using the rsync.net cloud provider this way, or any shell account
|
|
on a typical unix server, such as a Linode VPS can be used.
|
|
|
|
The following are known limitations of this release of the git-annex
|
|
assistant:
|
|
|
|
* On Mac OSX and BSD operating systems, the assistant uses kqueue to watch
|
|
files. Kqueue has to open every directory it watches, so too many
|
|
directories will run it out of the max number of open files (typically
|
|
1024), and fail. See [[bugs/Issue_on_OSX_with_some_system_limits]]
|
|
for a workaround.
|
|
* In order to ensure that all multiple repositories are kept in sync,
|
|
each computer with a repository must be running the git-annex assistant.
|
|
* The assistant does not yet always manage to keep repositories in sync
|
|
when some are hidden from others behind firewalls.
|
|
* If a file is checked into git as a normal file and gets modified
|
|
(or merged, etc), it will be converted into an annexed file. So you
|
|
should not mix use of the assistant with normal git files in the same
|
|
repository yet.
|
|
* If you `git annex unlock` a file, it will immediately be re-locked.
|
|
See [[bugs/watcher_commits_unlocked_files]].
|