Snapshots, according to the Windows manual, only work on an individual document and only on the text of that document. Which makes sense, when you think about it – I’m about to make a revision to a scene and want to bookmark how the text was before I start mucking with it. That snapshot doesn’t affect any other document in the project – and BTW, snapshots don’t capture notes, synopses or meta-data.
The manual itself says:
The key thing to understand about Snapshots is that they provide a way to set save points for individual items in the binder. They are not a tool for providing an overall snapshot of the entire project, structurally speaking, and are probably not the best tool for taking a quick snapshot of your entire draft.
With a source control program, which was originally designed for multi-engineer computer programming projects, it allows you to add/remove/edit files in the overall project, but keep track of all of those changes separately – originally via check out/in workflow, but modern versions use a more collaborative approach. Example: I create a new function in a new file. Ashley checks that file out, adds more functionality, and checks it back in. Bob checks it out, does a code review, fixes a couple of bugs, and checks it back in. I check it back out, compile the whole program, run it through its tests, declare it good, and increment the project version. Anyone who checks out that version now gets all the project documents as they existed when that version was created.
Under the newer collaborative model, I create my own local copy of the project by downloading the latest version (or a specific version) from the repository. I now have my own copies to work on, independent of anyone else’s. When I commit my edits back to the repository, they get written back up (if they were the only edits in that section of code) or I get alerted to a conflict that Ashley also worked on the same function I did. Since she committed first, I look at her changes and compare them to mine, resolve them, and commit the resulting file. If Bob incremented the version before I did so, then my commits go back to the version I’d checked out from, not barraging up the new version.
For software projects, the ability to keep track of changes/differences in each text file is key. Single developers on small projects will often use this systems just to keep different versions straight when developing new versions or backporting bug fixes into older versions.
So how does this relate to Scrivener? Well, I don’t think a source control engine would handle the RTF and XML file structure well, nor would I want them to. Project-level granularity is good enough. However, being able to take a point-in-time backup of the entire project and save it as a separate version that I could easily revert to would not only be a great way to help manage project versions, but to also handle syncing between multiple devices or collaborating with multiple authors. It would fix some of the issues with using Dropbox and other file-sync solutions because it’s not an “always sync” type of solution.
I can do this now, clumsily, with my favorite version control tools and Scrivener. I just have to save the files, shut down Scrivener, use the tools to make the commit/check-in, etc. Gets a little time-consuming. But if that kind of integration was built in to Scrivener (transparently call the tools of your choice without re-implementing how they work, open and close projects as required) it would be pretty cool. And you could use Scrivener snapshots as they are today, to continue having a file-level snapshot granularity.