Automatic codebase backup

[wallabra]

Summary

I request an important, and useful, feature, which would allow Multihack users to quickly restore files lost by the synchronizer (which happens quite commonly, to be honest): automatic backup creation.

Description

This feature would be capable of automatically creating a backup of a project's changes (or the whole project itself) everytime a change is made to a file. This backup would likely be a compressed tarball, with additional metadata (to describe the project and room name, for identification), and would be saved in a Multihack-specific folder (such as %APPDATA%\Multihack on Windows, or ~/.multihack on Unix).

If the backups are deltas, one can simply use an initial state tar, load it to a temporary folder, and apply the deltas to the folder, one by one, until we reach the desired backup state.

This would make the plugin more productive (and usable), since the loss of a file would be not but a small nuisance, instead of a worrisome event.

Versions

• OS: Windows 7 64-bit.
• Brackets: Release 1.13, build 1.13.0-17696 (release 49d29a8bc). Built on Thursday, January 14th 2018, 08:13:54 GMT+01:00.

[t-mullen]

The CRDT data model used for sync is in the process of being completely replaced (the sync errors are mostly due to the buggy model we're using now.

Traditional deltas applied to a tarball wouldn't converge, but the idea of "snapshot" backups is sound. I'll keep this in mind for the next iteration.

[wallabra]

The deltas could instead be saved as a zip file containing a specific format:

• a METADATA.XML file, containing information about the author, and other similar metadata:

<meta>
    <!--
    Author of this delta, including
    name and (optionally) IP address.
    -->
    <author>
        <name>John Doe</name>
        <ip>127.0.0.1:1234</ip>
    </author>

    <!--
    Time this delta was received.
    -->
    <date>
        <!-- Unix epoch. -->
        <unix>1539270342</unix>

        <!-- Human readable date. -->
        <utc>Thu Oct 11 15:05:42 2018 UTC</utc>
    </date>

    <!--
    Basic view of what happens, without showing
    what exactly has changed.
    -->
    <content>
        <!-- New file -->
        <file oper="create">/doc/readme.md</file>

        <!-- Modified file -->
        <file oper="change">/doc/index.html</file>

        <!-- New folder -->
        <dir oper="create">/src/win32</dir>

        <!-- Deleted folder -->
        <dir oper="delete">/src/windows</dir>
    </content>
</meta>

• a CONTENT folder, with the contents of the delta;
• a DTDESC file, which contains delta-related fields (used by the CST conditions below); and
• a CONDITIONS folder, containing the relationships (conditions) between this and other deltas, such as:

<condition>
    <type>Translucency</type>

    <if>
        <or>
            <isTrue oper="larger">
                <field>date</field>
                <otherField>date</otherField>
                <default>true</default>
            </isTrue>

            <isFalse oper="equal">
                <field>pos</field>
                <otherField>pos</otherField>
                <default>true</default>
            </isFalse>
        </or>
    </if>
</condition>

We could also use a more specific syntax for the files within CONDITIONS.

The delta types are better described in these logs I extracted from IRC:

Among the kinds of delta conditions, are included:

• Assumptions: conditions that make the delta valid to apply within a state S. For example, if from ABCDE I erase "CD" using Backspace, it is an implicit assumption that there must be a CD, to the right of an AB at position 0, and to the left of an E at position 4.
• Superiority: conditions that make the delta valid over another delta, O. For example, if Ana writes ABCDE, and someone erases just the E, but someone else erases the DE, and both deltas conflict with each other, the DE wins, because the DE's delta is a superset of the E's delta.
• Translucency: conditions that make two deltas valid at the same time. For example, if Jack writes ABCDE, then Joe erases the DE, but Jack wrote FG on top before acknowledging of Joe's erase, it is only logic that what Joe erased should be replaced by what Jack wrote, replacing the erased data. The condition is that the positions are equal, and therefore the merging goes like this: erasing first, writing after.

Assumption, Translucency, Superiority. The Conflict Solver Triplet (CST).

If you prefer, I may just implement myself a simple library to deal with CST delta conditions, and upload it to npm.

[t-mullen]

You're welcome to try and patch this version of Multihack, but I'm more interested in solving the issues in the underlying CRDT and editor bindings so we don't lose data or get desyncs at all.

This was a first attempt at realtime collab, so there's some glaring design flaws in my approach here (I knew very little about CRDTs or even the Brackets extension API when this was written). Everything is in the process of a ground-up redesign.