Revisions Mode vs Snapshots vs Backups

Confused by the awkward zoo of version control affordances offered within Scrivener. Why not integrate all three in an intuitive and easily managed multiuser/suggest/edit/compare/revise/timeline/branching multithreaded versioning system?

Probably because that would require writing a brand new RTF parsing engine that was able to perform that, rather than working with the native MacOS TextKit engine and adding on from there.


Why replace three distinctly different systems,with different use cases, with a complicated…

… which doesn’t sound intuitive at all?

1 Like

Ah, you use Git too? :wink:

Because they are all the same thing. You are confusing integration with complexity. I am a user interface designer. I suggest and build intuitive solutions. What is confusing is the notion that a hairbrush is a different devise when it is used on a Labrador instead of a Pointer.

No. But I can think.

Please explain. I’ve designed plenty of Mac applications in many use domains. I’ve never found that good interaction design can’t be accomplished as a result of apple standards.

No, you are suggesting that a hairbrush is the same as a hairdryer because both are used on hair.

Reread my original post.

A backup creates an independent copy of the entire project.

A snapshot creates a copy of an individual document, allowing simple comparisons between versions within a single project. It is probably the closest to a “version control” tool in the sense that systems like Git use the term.

Revision Mode provides tools for indicating changes within a single copy of a document.

While there are technical reasons why Scrivener does not offer a “multiuser/suggest/edit/compare/revise/timeline/branching multithreaded versioning system,” the primary reason is that such a system would be out of scope. Scrivener is a tool for writers, not programmers and not “content managers.”

Ideally, both revisioning and snapshots could be used to track changes and to allow input from others. Both are only different in how they were coded and I suspect, when they were coded. Both appear very much to more the product of existing code library’s and their respective strengths and omissions. What you want when designing a product is to teach once. One metaphor for every instance of a edit. Learn it once, use it everywhere. If you want you can offer the user ways in which to specialize affordances to circumstance, but that shouldn’t restrict the ease of use and universality of experience.

Here is some text. Do you want to edit it? Do you want to see the edits you’ve made to get to this place? Do you want to share your edits with others? Do you want to see the difference between two branches of the same edit history of your text? Do you want to see two versions and the delta between them as you work? Do you want to commit to one edit in the past, to bring that edit forward in time to the present document? This is all of it versioning. There are conventions for how to deal with and present versioning functionality to the user (slidable realtime timelines with branching, onion skinning (where historical edits fade out with time), color coded multi-user team editing, closures, etc.

If I am forced to learn several sets of tools to accomplish the same edits just because I am looking at one type of document or I am looking at my document in one type of view or tool set, and if I am restricted to which tools and which functionalities and which views are available for each of these sets of tools that I had to learn as separate affordances… not good. Why?

I will let you do your own research here in the forum posts on the history of Scrivener’s design goals, since you seem to have so much spare time.

You’re not.
Having a backup of the current version, somewhere safe, in case my computer explodes or get stolen or whatever, has nothing to with editing.
Revisions mode is for me a way to know what parts of the text I have revised, not how they were changed.
Snapshots give me a tool to compare two versions of the same text, while I am writing, in case I rewrite but am unsure if the nes version will be better.

So it’s not at all about “the same edits”.

I prefer to use dedicated tools for each task, not some kind of Swiss-army-knife all-in-one tool to handle everything? Why? Dedicated tools usually give a better result, and it’s also a way of keeping my work structured:
What part should I be working on today? (Labels or Revision mode)
Is this phrasing better than the original? (Snapshots)

Sorry if I offended you. I certainly didn’t mean to imply that only a Git user could come up with what you’ve described. It just sounded like a standard version control system, something I’ve often thought would be fun to have in a writing tool.