27 lines
1.2 KiB
Markdown
27 lines
1.2 KiB
Markdown
Imagine putting a git-annex drive in a time capsule. In 20, or 50, or 100
|
|
years, you'd like its contents to be as accessible as possible to whoever
|
|
digs it up.
|
|
|
|
This is a hard problem. git-annex cannot completly solve it, but it does
|
|
its best to not contribute to the problem. Here are some aspects of the
|
|
problem:
|
|
|
|
* How are files accessed? Git-annex carefully adds minimal complexity
|
|
to access files in a repository. Nothing needs to be done to extract
|
|
files from the repository; they are there on disk in the usual way,
|
|
with just some symlinks pointing at the annexed file contents.
|
|
Neither git-annex nor git is needed to get at the file contents.
|
|
|
|
(Also, git-annex provides an "uninit" command that moves everything out
|
|
of the annex, if you should ever want to stop using it.)
|
|
|
|
* What file formats are used? Will they still be readable? To deal with
|
|
this, it's best to stick to plain text files, and the most common
|
|
image, sound, etc formats. Consider storing the same content in multiple
|
|
formats.
|
|
|
|
* What filesystem is used on the drive? Will that filesystem still be
|
|
available?
|
|
|
|
* What is the hardware interface of the drive? Will hardware still exist
|
|
to talk to it?
|