blob: c9c5754d7e609820251e04c42eb6d385f587d6b2 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
|
[[!meta title="what git-annex is not"]]
* git-annex is not a backup system. It may be a useful component of an
[[archival|use_case/bob]] system, or a way to deliver files to a backup
system.
For a backup system that uses git, take a look at
[bup](http://github.com/apenwarr/bup).
* git-annex is not unison, but if you're finding unison's checksumming
too slow, or its strict mirroring of everything to both places too
limiting, then git-annex could be a useful alternative.
* git-annex is more than just a workaround for git limitations that might
eventually be fixed by efforts like
[git-bigfiles](http://caca.zoy.org/wiki/git-bigfiles).
* git-annex is not some flaky script that was quickly thrown together.
I wrote it in Haskell because I wanted it to be solid and to compile
down to a binary. And it has a fairly extensive test suite. (Don't be
fooled by "make test" only showing a few dozen test cases; each test
involves checking dozens to hundreds of assertions.)
* git-annex is not [git-media](https://github.com/schacon/git-media),
although they both approach the same problem from a similar direction.
I only learned of git-media after writing git-annex, but I probably
would have still written git-annex instead of using it. Currently,
git-media has the advantage of using git smudge filters rather than
git-annex's pile of symlinks, and it may be a tighter fit for certian
situations. It lacks git-annex's support for widely distributed storage,
using only a single backend data store. It also does not support
partial checkouts of file contents, like git-annex does.
|
