Twine integrated revision control

[klembot]

Originally reported by: LemonPi (Bitbucket: LemonPi, GitHub: LemonPi)

---

One challenge users of Twine face is keeping track of changes between versions of their story. Releases could be months apart and across many different passages and functions. Something that could help greatly with this is integrated revision control (or just any kind of revision control at all, as many users are not familiar with more software oriented tools).

This could be implemented by internally keeping the passages as separate files (or separate sections of one file, basically anything to allow easy separation), and then every time the user publishes, you ask if they want to "snapshot" (commit) this published version, with a prompt for a description of the changes. Internally, all you do is a git commit (git > hg) on such action.

The most basic prototype for showing them the changes would be running git diff in a text block. Something more advanced would be to colorize the current passages in story graph view, with each block having some green and some red depending on changes.

I think this could be quite easily done and would be a very useful addition to Twine. Like the branch exploration feature, I would be willing to try to add this once the refactor branch stabilizes.

---

• Bitbucket: https://bitbucket.org/klembot/twinejs/issue/235

[klembot]

Original comment by furkle industries (Bitbucket: furkle, GitHub: furkle):

---

What about a MutationObserver for undo/redo? It might be fairly trivial to keep changes and deletions in a stack and move back/forward within it.

[klembot]

Original comment by Chris Klimas (Bitbucket: klembot, GitHub: klembot):

---

Right now, the "official" solution for using source control with Twine is grunt-entwine-quickstart.

[klembot]

Original comment by Chris Klimas (Bitbucket: klembot, GitHub: klembot):

---

Agreed on the utility of this idea, but not necessarily the implementation. A couple thoughts:

• It sounds like you'd like to draw on git as an external tool; remember that we also offer an online-only option, and I really want to try hard to provide parity.
• I'm leery of creating a veneer over git (or another source control tool), because we'd have to keep pace with any changes.
• It also imposes a learning curve on the end user. I don't have any statistics on this, but I would guess that most of our users have never used source control before.

But -- I do think revision history, and in particular undo (we really should have a way for a user to be able to undo deleting a passage) is something that is sorely needed. Right now my thought is to leverage something like redux for this, though that would involve a considerable amount of reworking of our data layer.