Whew yeah, I’m a huge fan of that File ▸ Back Up ▸ Back Up To… command prior to running any kind of large-scale search and replace—or really anything that would impact an unknown quantity of items in a difficult to reverse way, like deleting a keyword that is in use. I’m pretty sure I want to do the thing, but I’d rather have a zipped sidecar copy of the project called “The Novel - pre-before I changed Doug to Suzy.scriv.zip”!
Another approach more designed for this example is the practice of forking off a reference .scriv of each finished work when it comes to that point, compile settings and everything intact, so that future revisions can be spun off from the forked project and the copies left in the master WIP project can be considered loose backup references—research material not source material (and it isn’t difficult to keep that up to date at the conclusion of a revision cycle, either).
Or here’s another:
- Select all of the items you intend to bulk replace.
- Hit ⇧⌘5 and do a bulk snapshot with title.
- Use the Edit ▸ Find ▸ Project Replace… command with the selection filter on (or the Scrivenings route if you prefer, but that does come with the risk of hitting un-protected subdocuments).
Now in a year say if you’re positive this never had any awful effects, you can search for the title you gave in step 2 with the Snapshots Manager and nuke the whole backup for that action. There is very little investment in protecting the changed work beforehand, very little cost in keeping the protective measure around and little investment in removing it, once time has proven it was a safe move. I just think the concept of Snapshots is so much more powerful now that we can slice out bulk chunks like that as needed. It’s a tool that probably requires a little reexamination from us veteran users, who aren’t used to the concept of having 400 snapshots being anything other than ultimately very unwieldy down the road.
There are surely other approaches as well—what I’m getting at is that I think Scrivener does have good mechanisms for safeguarding our work that do not involve locking—snapshots only be one of them. So is the massive UI undertaking that would entail coding such a feature (again the whole program is built from the ground up as an always-on editor, we’re talking hundreds of buttons and switches that would have to have manual overrides built in just to do this—and it goes into the data model as well, not just the UI, this is a deep change to how the entire program is designed to work), and the potential confusions and oddities that would evolve from such a change, worth implementation if there are viable approaches that avoid the hazards that a lack of locking might bring—approaches which incidentally will also serve to protect the kinds of data that wouldn’t and shouldn’t be locked as well? I mean to say, a lock would have fixed the described problem of source material for other books in the binder, but it won’t solve the same action being done on too much of the current WIP, while preventive habits on the other hand protect both.
Maybe—don’t get me wrong, personally I would love a hard lock, from the Title on down in fact, no even touching metadata (a stance probably most would disagree with, but that’s another issue)—but this is something that has been requested since… well it wouldn’t surprise me if it were first brought up in the pre-Scrivener Gold days, thirteen years ago—it’s going on a little more than one year now!
I think our energies will be best spent finding good ways to make locking unnecessary, by either avoiding the scenarios that would make it so, or adopting preventive measures before executing potentially destructive functions.