jcbsnclr / ksync Goto Github PK

It seems that ksync is already used for the name of another synchronisation utility. A new name will need to be picked.

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:

• #2
• #3
• #4
• #5

Any feedback would be much appreciated.