Revision granularity

Hi, I am wondering if there is some option in the server side where I can give more “granularity”/“saving speed” to the revisions. What I mean by that is the only feature from Etherpad that I miss in HedgeDoc: the timeslider.

For example, if in Etherpad I wrote “This is a test. ” and then I deleted it, I get this history:

{
  "pad:asdasfaq": {
    "atext": {
      "text": "\n",
      "attribs": "|1+1"
    },
    "pool": {
      "numToAttrib": {
        "0": [
          "author",
          "a.CwaayRJ9brMJX2rh"
        ]
      },
      "nextNum": 1
    },
    "head": 14,
    "chatHead": -1,
    "publicStatus": false,
    "passwordHash": null,
    "savedRevisions": [
      {
        "revNum": 14,
        "savedById": "a.CwaayRJ9brMJX2rh",
        "label": "Revision 14",
        "timestamp": 1616608153392,
        "id": "f8ef7e4357705cef60bc"
      }
    ]
  },
  "globalAuthor:a.CwaayRJ9brMJX2rh": {
    "colorId": 9,
    "name": null,
    "timestamp": 1616608163510,
    "padIDs": "asdasfaq"
  },
  "pad:asdasfaq:revs:0": {
    "changeset": "Z:1>ag+ag$Welcome to the WMF etherpad installation. Please keep in mind all current as well as past content in any pad is public. Removing content from a pad does not mean it is deleted. Keep in mind as well that there is no guarantee that a pad's contents will always be available. A pad may be corrupted, deleted or similar. Please keep a copy of important data somewhere else as well",
    "meta": {
      "author": "",
      "timestamp": 1616606504556,
      "pool": {
        "numToAttrib": {},
        "attribToNum": {},
        "nextNum": 0
      },
      "atext": {
        "text": "Welcome to the WMF etherpad installation. Please keep in mind all current as well as past content in any pad is public. Removing content from a pad does not mean it is deleted. Keep in mind as well that there is no guarantee that a pad's contents will always be available. A pad may be corrupted, deleted or similar. Please keep a copy of important data somewhere else as well\n",
        "attribs": "|1+ah"
      }
    }
  },
  "pad:asdasfaq:revs:1": {
    "changeset": "Z:ah<af-ag*0|1+1$\n",
    "meta": {
      "author": "a.CwaayRJ9brMJX2rh",
      "timestamp": 1616606508091
    }
  },
  "pad:asdasfaq:revs:2": {
    "changeset": "Z:2>1|1=1*0+1$T",
    "meta": {
      "author": "a.CwaayRJ9brMJX2rh",
      "timestamp": 1616606508658
    }
  },
  "pad:asdasfaq:revs:3": {
    "changeset": "Z:3>4|1=1=1*0+4$his ",
    "meta": {
      "author": "a.CwaayRJ9brMJX2rh",
      "timestamp": 1616606509157
    }
  },
  "pad:asdasfaq:revs:4": {
    "changeset": "Z:7>2|1=1=5*0+2$is",
    "meta": {
      "author": "a.CwaayRJ9brMJX2rh",
      "timestamp": 1616606509666
    }
  },
  "pad:asdasfaq:revs:5": {
    "changeset": "Z:9>5|1=1=7*0+5$ a te",
    "meta": {
      "author": "a.CwaayRJ9brMJX2rh",
      "timestamp": 1616606510171
    }
  },
  "pad:asdasfaq:revs:6": {
    "changeset": "Z:e>1|1=1=c*0+1$s",
    "meta": {
      "author": "a.CwaayRJ9brMJX2rh",
      "timestamp": 1616606510662
    }
  },
  "pad:asdasfaq:revs:7": {
    "changeset": "Z:f>1|1=1=d*0+1$t",
    "meta": {
      "author": "a.CwaayRJ9brMJX2rh",
      "timestamp": 1616606511175
    }
  },
  "pad:asdasfaq:revs:8": {
    "changeset": "Z:g>1|1=1=e*0+1$.",
    "meta": {
      "author": "a.CwaayRJ9brMJX2rh",
      "timestamp": 1616606511662
    }
  },
  "pad:asdasfaq:revs:9": {
    "changeset": "Z:h>1|1=1=f*0+1$ ",
    "meta": {
      "author": "a.CwaayRJ9brMJX2rh",
      "timestamp": 1616606512162
    }
  },
  "pad:asdasfaq:revs:10": {
    "changeset": "Z:i<1|1=1=f-1$",
    "meta": {
      "author": "a.CwaayRJ9brMJX2rh",
      "timestamp": 1616606514524
    }
  },
  "pad:asdasfaq:revs:11": {
    "changeset": "Z:h<1|1=1=e-1$",
    "meta": {
      "author": "a.CwaayRJ9brMJX2rh",
      "timestamp": 1616606515610
    }
  },
  "pad:asdasfaq:revs:12": {
    "changeset": "Z:g<1|1=1=d-1$",
    "meta": {
      "author": "a.CwaayRJ9brMJX2rh",
      "timestamp": 1616606516110
    }
  },
  "pad:asdasfaq:revs:13": {
    "changeset": "Z:f<d|1=1-d$",
    "meta": {
      "author": "a.CwaayRJ9brMJX2rh",
      "timestamp": 1616606516613
    }
  },
  "pad:asdasfaq:revs:14": {
    "changeset": "Z:2<1|1-1$",
    "meta": {
      "author": "a.CwaayRJ9brMJX2rh",
      "timestamp": 1616606517112
    }
  }
}

But if I do the same (with the same writing speed) on HedgeDoc, I get this:

{
  "revision": [
    {
      "time": 1616608875010,
      "length": 0
    }
  ]
}

Which is only:

{
  "content": "",
  "patch": [],
  "authorship": []
}

I think the “granularity” of Etherpad is convenient for discourse studies, since we can have not only the final text but the way it was written :smiley: Plus, with the timeslider reading mode some text could be easier to understand since you would read as it was written, this is a powerful and new mode of reading that in humanities could be very appreciated.

Because of performance reasons hedgedoc creates a new revision only every ~5 minutes. There is no way to adjust this. (Except if you change the code)

Thanks for the reply. Are those “performance reasons” related to the operational transformation? I just wonder so I can dig more in how HedgeDoc works

Well the idea is to don’t stress the DB more than is needed. What exactly would break if you’d save every second is hard to guess, but feel free to to experiment. Maybe you want to report back here about your findings…

That could be interesting, where can I find that 5 minutes limitation?

I’d look in the folder under note or ot, but I’m currently not deep enough in the 1.x code base to be more helpful.

https://github.com/hedgedoc/hedgedoc/blob/2ea40bb98d80ca765f60f9b69d26d5be12188231/lib/models/revision.js#L208

There you should find it :slight_smile: