This is from a thread I posted recently - Imho I think it merits consideration as a feature in the next version.
I have finished my first book. It is done and dusted and published.
While I write my new book (a sequel) I regularly need to open my first project to refer to things that I wrote about characters, old notes, document notes, references etc.
But I don’t want it to keep going through the same ‘backing up’ either every two seconds or when closing. One reason is that it is really annoying 8), but the second reason is that I may accidentally make changes and I really don’t want it to change.
I do realise that there are workarounds … such as creating a MASTER backup and filing it away. However this just adds more complication to the already complicated collection of project files that need to be managed.
I think that a ‘Lock’ function button in the main tool bar would be an even better option. Especially were I to have two or three more books in the series. The Lock function, when clicked, would do look something similar to the Apple system where a pad lock would appear open or closed, and maybe the tool bar background would change colour. By locking the project, it would turn it into a ‘read only’ project and exempt it from all backup processes except a ‘Save as’.
When you are done working on a project, you can switch off backups for it with the File/Back Up/Exclude From Automatic Backups menu command (note there is a bug in the current stable version that makes it look like nothing happened, but if you use the beta version you’ll see a checkmark on that menu item).
I’m not sure what you mean about it backing up every two seconds though, there is no combination of settings that would cause that to happen. You see the backup progress meter come up every two seconds while working, or do you mean something else? Not even auto-save happens that frequently (it waits until you pause for two seconds, which means it may happen even infrequently for busy people that click around a lot).
This is what I do, but I do a couple of things to keep things sane:
The master backup is always zip compressed so that I can’t even open it in Scrivener. Now whenever I want to take a look at this old project, I just double-click the .zip then open the project and usually delete it once I’m done—leaving just the .zip. That gives me (a) a safe copy that cannot be accidentally edited and (b) a volatile temporary copy that I can use without fear of damaging anythign important because I’m just going to delete it when I’ve pulled what I was looking for.
I put all of these zips into appropriately named folders. For myself, that means stashing them in an sub-folder under a master folder called “Archive” where dump all stuff that is completed or abandoned. I also add ‘FINAL’ to the .zip file name to make searching easier in the future.
That method keeps the project static and impossible to confuse with anything else.
There are no plans to add a project-wide lock though, it has been requested and rejected a few times in the past. Since this can already be effectively done using the OS or convention, it doesn’t really add a lot to the software, and meanwhile it would require a major rewrite of just about every little thing you see, because the data model was built exclusively upon a model of full read/write permissions. Practically everything you do in Scrivener has a disk reaction.
Something to consider, however…
Why not drag all of that stuff over to the new project so that you have it immediately available? It’s not changing anyway, from what I gather.
There is of course a simple way of doing this — I assume it will work — and that is to select the .scriv project in question in a finder window, click on it, call up the information pane (Cmd-i, “Get Info” in the File menu, or through Ctrl/Right-click) and set the permissions to “Read only” for all the groups.
Yes, that will work, all you need to do is set the top level “.scriv” container to read-only. It’s worth mentioning that it will no longer load in Scrivener, so you end up with a similar result as .zip—you have to do something to create a copy that can be opened for reference.
Perhaps it would help if you explained what you consider ‘remotely satisfactory’ would look like. AmberV’s solution of unzipping your Master Backup (i.e. the project file from which you compiled your first book) and then deleting might take a few seconds, but it’s a perfectly good setup. Likewise the Exclude From Automatic Backups advice, which might be coupled with setting your autosave function to something outlandish like 50,000 seconds. Of course, you’d have to remember to toggle that setting back to your preferred length of time for other projects, and it wouldn’t be satisfactory if you were working on the second book while reading the first.
Mr X’s advice about dragging your reference material from your first book project is very sound. That way you won’t have to re-open the original project at all. In fact, if you are writing a sequel that may even turn into a series, I would recommend creating a project that contains only reference material that can be kept open simultaneously with your current book. That way your reference materials can be updated. Otherwise, perhaps think about investing in database software to manage your references, and use Scrivener purely as a writing platform.
It would also probably help if you explained what you mean by ‘complicated collection of project files’. One of Scriv’s main selling points for me is that I don’t have to manage a collection of files. Scriv does that for me. All of my text files are in their respective projects. My backups are exactly where they’re supposed to be (and untouched unless I need to restore, which I never have), and my current project resides in my Documents folder. Easy as pie.
A long, long time ago - OK, several years - I recall this issue of locking projects arising. I seem to remember the developer explaining his concern that if projects could be locked, that would lead to a lot of support requests where users had locked their projects accidentally, or without realising it, or if they did realise, had forgotten how to unlock them. As I say, it was quite a while ago, and my memory may be faulty - but I seem to remember that the explanations for not providing an easy, explicit locking mechanism made sense to me at the time.
