Close but Not Backup?

I have automatic backups in place when I close which is great but sometimes I just need to open my Scrivener file to check or compile something so no changes are made. I’d like the addition in the file menu a close and don’t backup option so I don’t have a bunch of backups that are all the same file.

Thanks, I have something similar to this in our notes for looking into in the future. At the moment there aren’t any simple one-offs, save for temporarily toggling the backup system off before closing, or individually excluding the project itself from backing up via the File/Back Up/Exclude from Automatic Backups toggle. You’ll need to remember to turn that back on the next time you open it however. I suppose a third alternative—one that I would take myself—is to simply duplicate the project you wish to “passively” open, opt it out of backups as described, and then trash it once you’re done with it. That’s a good technique for whenever you wish to experiment or do something without modifying the original, but it does mean clutter and potential for confusion if the copies aren’t cleaned up promptly.

With no knowledge of how Scrivener stores its backups, could a version control system be used? If there are no changes, no new version. Of course exposing or hiding a new interface to backups might be interesting.

A distributed revision control system might also help with backups, but again conflict resolution when someone does make conflicting edits on different machines would be challenging.

The issue is that the project state very often does change, even if the individual component files don’t. You might have created a collection, say, in order to experiment with a different Binder order. Or you might have very carefully set up the window layout you like. You didn’t write anything, but Scrivener will still recognize the need for a backup.

Katherine

Yes, there are certainly external solutions as well. It’s also worth noting that the built-in system is pretty flexible. There are three basic modes of operation, along with other settings:

  • Fully automatic based on sessions is the default behaviour.
  • Manually operated, where the only time you get a backup is when you trigger one. File/Back Up Now and the option to bind Cmd-S / Ctrl-S to creating a backup, are the two most convenient triggers.
  • A combination of the two can be achieved with settings. For example it can back up when you open the project, as well making use of one of the above methods to make your own backups more frequently.

There are some other good options in the Backup settings pane that make it worth investigating how it works. One thing to consider, in terms of better controlling when backups happen, is that since there is a menu command that triggers a backup, external automation becomes easily obtainable.

As to that, there wouldn’t be much overlap between the two (which is a good thing I would say). Our backups are very simple, they are zipped copies of the entire project stored in a central location away from the original project. Version control would be working with the project itself, not the backup copies.

My solution has been to turn off backup on close and backup on open. Those aren’t so useful for me anyway, since I might leave a project open for days. Also, I do frequently open a different project just to check something.

Instead, I have a macro such that every time I press Ctrl-B it backs up to a thumb drive and to OneDrive. I’m good about clicking it regularly.