local repo format migrations

[jbenet]

though this should rarely happen, sometimes we'll need to change formats of the repository files; this includes config key changes, and data inside leveldb. we should never break people's objects, so that means we need to handle these upgrades with great care.

We probably should use something like a repo-version with migrations. one possible way to do this is: we have a single repo version, every time we make format change we increment the repo version, and add a tool repo_migrate_<old>2<new> that performs the update. We should then be able to apply each script in sequence.

It would be easiest to write these in go, given much of the formatting will have to do with datastore keys or protobufs. things that would make this easier:

• a datastore tool (cli tool to manipulate arbitrary datastores)
• a repo tool (standalone tool that understands config, datastore, blockstore, + merkledag) and can manipulate them.

[jbenet]

I wrote down some generalized thoughts on repos + migrations here: jbenet/random-ideas#33 -- i'd like to see go-ipfs have something like this:

> ls ipfs/bin/repo-migrations
1-to-2
2-to-3
3-to-4
4-to-5
5-to-6
6-to-7

> ipfs/bin/repo-migrations/1-to-2
repository version: 3
already up to date.

> ipfs/bin/repo-migrations/3-to-4
repository version: 3
applying path: 3-to-4
repository version: 4

> ipfs/bin/repo-migrations/3-to-4 --revert
repository version: 4
applying patch: 4-to-3
repository version: 3

> ipfs/bin/repo-migrations/run 1-to-7
repository version: 3
applying patch: 3-to-4
applying patch: 4-to-5
applying patch: 5-to-6
applying patch: 6-to-7
repository version: 7

[whyrusleeping]

i dont care about migrations until we alpha

[jbenet]

From now on we need to do migrations when changing the repo layout.

[whyrusleeping]

we do migrations now, it works: https://github.com/ipfs/fs-repo-migrations