For a few weeks I’ve sought to snapshot my whole Draft folder and I’ve finally discovered how, with CMD-5. But now I’m wondering why this is not more prominently place. Is there a reason this is to be avoided?
Cheers,
Keith
Hi Keith.
Why should it be avoided? No real good reason.
The only downside to taking a snapshot of that many documents or to be doing it often is the cumulative size of the project.
But if that is a “problem”, there are ways to manage the weight a project is worth in snapshot files…
(So in my humble opinion, project size for an argument against would be garbage.)
[I linked to an how to, explaining how to easily clean up the snapshots in bulk, at the bottom of this post.]
Here is what though: you don’t have to select all binder documents then take a snapshot of the whole. (You can, sure, but there is better…)
If (and that is how my setup is) you rely on Scrivener to auto-save your project after X seconds of inactivity, then you don’t have to manually save.
Freeing the save command/shortcut for something far more interesting.
You can link manual saves to Scrivener taking a snapshots of all (but only) your documents that were modified since your last manual save.
In other words, saving the projects takes a snapshot of ONLY the documents that have a difference to justify that new snapshot.
Meaning that the last snapshot of your documents sum up to your project as it was at the time of that last manual save.
Ain’t that great?
Here are the two concerned options:
(Windows screenshot)
(This combined with proper zipped and timestamped backup is all one needs to have his/her progress, steps (snapshots), and project secured.)
And by the way: the size of a project only really matters when it comes to sync through a cloud service, etc.
If you always work on your projects from the same computer, just don’t worry about it. 
If you ever feel the size of a project / number of snapshots has gotten out of hands:
1 Like
@manifolded : For a few weeks I’ve sought to snapshot my whole Draft folder and I’ve finally discovered how, with CMD-5. But now I’m wondering why this is not more prominently place. Is there a reason this is to be avoided?
I’ve written a little bit on this matter in the past, and the main issue I have with the notion is that it seems a bit wasteful and noisy to me, to snapshot everything, regardless of whether or not it is going to be (or has been, depending on how you use the tool) edited.
But to put a bit of a disclaimer to it, I’m coming at this from the frame of mind of one who presses Scrivener’s outlining capacties to the limit—sometimes paragraph level outline nodes, and rarely chunks of text so long I have to scroll the editor.
Where that is salient to the topic at hand is that my edits are far more surgical than someone who has 15 massive chapter-length documents. Every time they change a sentence somewhere, the entire chapter has to be snapshot—whereas with the way I work, 99% of the chapter’s content in the binder isn’t being touched, so to snapshot the several dozen binder items around the one with the two or three paragraphs I actually edited is just noise that makes it harder for me to find the snapshots that actually matter.
Now amplify that problem to the entire draft, and it makes even less sense to do this.
So all right, maybe one who uses Scrivener more like File Explorer with a folder of .docx file might conceivably actually edit the entire list of times in the Draft folder in a revision pass. All right, why not then? Go ahead. There is probably a pretty decent sized area between extremes where it might be conceivably useful to blanket snapshot everything, but I would say the tendency would be toward waste rather than efficiency, and particularly if we wish to encourage Scrivener’s design intent of being an outliner-based writing tool rather than a file-based document manager. We’re competing with our own design if we promote stuff that really only works well with the latter.
In most cases, my mind would wonder whether or not File ▸ Back Up ▸ Back Up To... is not the right tool for the job, even if a full-draft snapshot actually would be used with little waste. If all we want is to preserve how things were at a certain point, before a large revision, why not actually do that, instead of making our core project larger and really only capturing the textual state rather than the meta-state of the outline (notes, synopsis, label flags, etc.).
So with all of that said, maybe you can see why this isn’t a tool that is flashing itself in your face when you click on the Draft folder or something. It was always designed to be a kind of use-as-needed “save as” tool for individual chunks of text. The concession to take more than one at a time upon a selection is not meant to be an invitation to routinely spam the entire project—so naturally we’re not going to make that more prominent. If you get use out of doing that, great, it is possible to use it responsibly and effectively, but it’s not something we want to encourage because it would be very easy to abuse it without understanding the implications.
@GoalieDad : Is there a way to easily assess the size of snapshots in a windows project, do not have some of mac options.
I don’t think I understand the query, as checking the size of a folder in your file manager would not require “mac options”.
1 Like
Of all that was so far said, that is in my opinion the most important thing to consider.
Why the snapshot in the first place?
Snapshots are not a backup.
If the idea is to have a safe copy of your project in a specific state of development, use the backup functions.
Snapshots are not intended for that.
More even, snapshots without a real backup would be lost along the project anyways, should something bad happen. So as far as using them as a backup goes? no gain.
It’s perhaps a matter for debate. I would call anything that provides a system whereby historic copies are kept in an frozen state, which can be simply and easily restored over the current volatile copy, is a form of backup.
The larger question is whether one backup is good enough, and most would agree not. For example the backups you refer to, of the whole project, aren’t really safe either until you copy them off the machine. But that wouldn’t keep us from calling them backups, in the broad sense of the term.
Snapshots are just the first layer in an onion of copies that are kept relatively protected from accidental harm.
I.e. my suggestion had less to do with what a “real” backup is, and more to do with what feels to me a better answer to the overall question of how to embark on a larger revision. There are other answers as well, such as duplicating the whole draft folder in the binder. Some like to do that, though I’ve never been a fan as that makes search results and cross-links confusing. It’s less convenient to have that duplicate in another project entirely, but it also keeps thing cleaner in the main project. Snapshots are probably the most convenient, if all you need is text, and also the most functional for showing differences between revisions.
All around, there is no one right way, but a lot of options that will work better or worse depending preference and the state of the material, working habits and so forth.
I guess I’m imagining a combination of the two, a backup along with the diff tool feature of snapshots. I’m imagining having to hunt through a series of backups trying to find the moment in history when a certain bit of text changed and imagining it to be a laborious process.
I use snapshots for individual scenes and use the titled backup option. I do title in synopsis area and use return to enter new line of text, you can copy and paste that into a snapshot title to give lots of detail and make it easier to sort out purpose of the edit.
Probably the closest thing to that combination you speak of is the merge project feature, described in §5.3.2, under subheading, Merging Changes from One Project into Another. (Note: a Mac-only feature at the time of this writing.)
The idea here is that you would create a milestone backup for safe keeping, then continue editing for a while. When you wish to review everything that has changed, you would create a copy of the backup (important) that is strictly meant for comparison checking—something to dispose of later most likely. From that copy, you would import the current project and select the option to merge changes, when asked.
What that does is then build a Collection of every binder item that changed, and it will automatically snapshot all of those changed documents as well. So now you can go through and audit each change, using the Snapshot compare feature to help in that process. The key thing is that at this point both the current project and the one you copied and updated with the current project should be similar. So you could select one of either to discard if in reviewing the changes you change your mind about one thing or another. But do bear in mind that project merge is chiefly concerned with merging the binder itself, not the project settings. If you’ve made significant changes to the compile setup for example, Merge does not handle that. So in most cases I would advise only using the merge copy as a reference.
The question is whether that approach is efficient for how you work. On the plus side, you don’t really have to do much yourself while you work. You don’t have to remember to take snapshots. You don’t have to remember to turn revision mode on or off—you are depending upon the software to do all of that for you. So that can be a significant advantage to those that have a hard time forming habits of “documenting” their work as they revise. The downside is that it is a bit involved, requires a lot of project juggling, working in duplicate copies and keeping straight which is important to keep and which is disposable, etc.
Forming good habits gets you to the same place as the procedure described above, and of course since the machine isn’t doing it all for you, it allows you to personalise that procedure—to choose when a revision is significant enough to document, to maybe use a tool other than collections, etc.
On the matter of documenting revisions, I might as well link to this post. I don’t always use this approach, as it has a lot of overhead, but for projects where it is really important to know what changed, and why, it creates an invaluable track record and level of self-documentation to the project.