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
33
34
35
36
37
38
39
40
41
42
43
44
45
46
|
The [[syncing]] design assumes the network is connected. But it's often
not in these pre-IPV6 days, so the cloud needs to be used to bridge between
LANS.
## more cloud providers
Git-annex already supports storing large files in
several cloud providers via [[special_remotes]].
More should be added, such as:
* Google drive (attractive because it's free, only 5 gb tho)
* OpenStack Swift (teh future)
* Box.com (it's free, and current method is hard to set up and a sorta
shakey; a better method would be to use its API)
* Dropbox? That would be ironic.. Via its API, presumably.
* [[Amazon Glacier|todo/special_remote_for_amazon_glacier]]
* [nimbus.io](https://nimbus.io/) Fairly low prices ($0.06/GB);
REST API; free software
## limited space
When syncing via the cloud, space there is probably limited, so
users with more files than cloud space will want to be able to use the
cloud as a temporary transfer point, which files are removed from after
they've propigated out.
Other users will want to use the cloud as the canonical or backup location
of their data, and would want a copy of all their files to be kept there.
That's also ok.
git-annex will need a way to tell the difference between these, either
heuristically, or via configuration.
Also needed for USB keys and Android gadgets.
## storing git repos in the cloud
Of course, one option is to just use github etc to store the git repo.
Two things can store git repos in Amazon S3:
* <http://gabrito.com/post/storing-git-repositories-in-amazon-s3-for-high-availability>
* <http://wiki.cs.pdx.edu/oss2009/index/projects/gits3.html>
Another option is to not store the git repo in the cloud, but push/pull
peer-to-peer. When peers cannot directly talk to one-another, this could be
bounced through something like XMPP.
|
