Filesystem versioning, rollback/archive support

[jcbsnclr]

Right now, as of the latest commit (41d9f8b), we keep track of the history of the filesystem; every modification of the filesystem structure creates a new root node, and appends that to the filesystem's history.

This means that we should have all the infrastructure in place to implement rollbacks and archiving of the filesystem, however I need to work out the best way to approach this. The issue at hand is that, essentially, synchronisation works roughly as follows:

if remote hash doesn't match local hash:
    compare timestamps
    if local copy newer than remote copy:
        push to server
    else if local copy older than remote copy:
        fetch from server

This works perfectly well when the filesystem is always on the most up-to-date revision, however where it falls apart is when you rollback to an earlier revision of the filesystem. If we were to naively just set an older node as the new current revision of the filesystem, then clients would see that the file timestamps are now older than what they have stored locally, and thus would push to the server their local changes, which would simply revert the filesystem back to what it was before the rollback.

I need to determine how to notify clients to the fact that a rollback has occured, and that they should re-base the local sync based on the new rollback (ideally, also performing one last sync from the client -> server to ensure any local changes are not lost in the process).

Beyond synchronisation, we should have the infrastructure in place to allow for the server to:

• fetch files from an older revision of the filesystem
• get a listing of an older revision of the filesystem

The features planned as part of this issue are:

• fetch files from an older revision of the filesystem #2
• get a listing from an older revision of the filesystem #3
• generate a .tar archive based on an older revision of the filesystem #4
• synchronise clients with server rollbacks #5

Any feedback would be much appreciated.

[jcbsnclr]

In regards to #5 , I think as a cheap, stop-gap solution it should be doable to perform rollbacks by:

1. cloning an old revision of the filesystem tree
2. update all their timestamps
3. store it as the latest revision of the filesystem
   This should allow for the current sync functionality to remain unchanged, while enabling rollbacks.

This does introduce the issue of file metadata no longer being correct, however; later on, it would be ideal to support some other means of notifying clients to rollbacks, but this solution should work for now at least.