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
33 lines
2.1 KiB
Markdown
33 lines
2.1 KiB
Markdown
When migrating large file repositories to git-annex that are backuped in a way that uses an rsync-style mechanism (e.g. [dirvish](http://www.dirvish.org/)) and thus keeps incremental backups small by using hardlinks, space can be saved by manually reflecting the migration on the backup. So, instead of making a last pre-git-annex backup, migrating, and duplicating all backupped data with the next backup, I used the <del>attached</del> migrate.py file below, and it saved me roughly a day of backuping.
|
|
|
|
A note on terminology: "migrating" here means migrating from not using git-annex at all to using it, not to the ``git annex migrate`` command, for which a similar but different solution may be created.
|
|
|
|
**WARNING**: This is a quickly hacked-together script. It worked for me, but is untested apart from that. It's just a dozen lines of code, so have a look at it and make sure you understand what it does, and what migrate.sh looks like. Take special care as this tampers with your backups, and if something goes wrong, well...
|
|
|
|
First, have an up-to-date backup; then, git annex init / add etc as described in the [[walkthrough]]. In the directory in which you use git-annex, run:
|
|
|
|
$ python migrate.py > migrate.sh
|
|
|
|
Then copy the resulting migrate.sh to the equivalent location inside your backups and run it there. It will move all files that are now symlinked on the master to their new positions according to the symlinks (inside .git/annex/objects), but not create the symlinks (you will do a backup later anyway).
|
|
|
|
After that, do a backup as usual. As rsync sees the moved files at their new locations, it will accept them and not duplicate the data.
|
|
|
|
**migrate.py**:
|
|
|
|
#!/usr/bin/env python
|
|
|
|
import os
|
|
from pipes import quote
|
|
|
|
print "#!/bin/sh"
|
|
print "set -e"
|
|
print ""
|
|
|
|
for (dirpath, dirnames, filenames) in os.walk("."):
|
|
for f in filenames:
|
|
fn = os.path.join(dirpath, f)
|
|
if os.path.islink(fn):
|
|
link = os.path.normpath(os.path.join(dirpath, os.readlink(fn)))
|
|
assert link.startswith(".git/annex/objects/")
|
|
print "mkdir -p %s"%quote(os.path.dirname(link))
|
|
print "mv %s %s"%(quote(fn), quote(link))
|