Document locking

Zi
Zibip
Posts: 8
Joined: Thu Feb 07, 2013 11:22 am
Platform: Mac

Fri Feb 23, 2018 12:27 pm Post

One year on since the last post in this thread... I guess we're not getting this feature, but I would like to add my voice to the request. Especially after I published an eBook that had a random word dropped into a sentence due to an absent-minded search attempt in the final draft... Imagine if it was a dead tree publication!

Ia
Ian Stewart
Posts: 7
Joined: Mon Mar 12, 2018 8:32 am
Platform: Mac

Mon Mar 12, 2018 8:43 am Post

Apologies for reviving this post but Scrivener is my favourite writing software but I no longer use it because the document cannot be locked. This in itself is not a problem, as on a Mac a warning comes up asking if you want to save changes should you accidentally change something, However Scrivener has overridden this safeguard.
As I go to research libraries and type extensive notes, which I keep forever, the chances of accidentally changing something over several months increases. I know that probably nothing has been changed but probably is not good enough, I need to know for certain. Even the most basic, simple text editor has this.
I now use either IAWriter or MacJournal repurposed. I occasionally use Scrivener for rough notes but not for anything that I need to keep. I know you recommend snapshots but for me it is convoluted and not a natural way of working.
Unfortunately the almost perfect writing software is unusable only because you have overridden a basic Macos facility that I take for granted.

User avatar
AmberV
Posts: 22063
Joined: Sun Jun 18, 2006 4:30 am
Platform: Mac + Linux
Location: Santiago de Compostela, Galiza
Contact:

Mon Mar 12, 2018 3:18 pm Post

Unfortunately the almost perfect writing software is unusable only because you have overridden a basic Macos facility that I take for granted.


It sounds like you are referring to how some applications work with individual documents you open, like Scapple or .txt files—i.e. simple formats that can be loaded entirely into memory at once and operated on purely “off disk” until you choose to save the file (or not). There really isn’t much of a comparison between formats like that and a program like Scrivener. I just tried three other programs that work more like Scrivener, where one loads a container that houses potentially thousands of files and only loads into memory the ones you work on within that session, and out of all of those, none of them had some kind of overarching “Are you sure you want to quit without saving changes?” when closing the container/database/etc.

It is (a) not a feasible mechanism for this kind of software, and (b) there is no infrastructure for it on the Mac even if it were. So we aren’t “overriding” anything, and we aren’t doing anything terribly out of the ordinary for this kind of software.

I will agree with you that locking would be nice in Scrivener, and it isn’t uncommon to find locking in database style programs—but it is a little more complicated than you seem to be thinking it would be, and of the one example I tried that is very much like Scrivener in this regard (Ulysses), it works exactly the same, with no locking.

Consider for example if you have one locked paragraph in a 100-item Scrivenings session (or a section of sheets in Ulysses). What happens then? Is there an immutable chunk of text in the middle of your file? If you change the font wholesale on that 100-item chunk of text, are patches of it ignored if locked? That could result in some embarrassing mistakes down the line if you thought the font was changed and never noticed until a reader wondered why there was suddenly a Courier paragraph in the middle of the book. Or what if you loaded that chunk of text with the intention of bulk search and replacing a character name? These are not challenges that a more typical database style program has to face—where one doesn’t consider chunks of text in the outline to be smaller ingredients in a longer span of text. It’s probably not an impossible problem to work around, surely, but I have a difficult time visualising an elegant approach to these problems.

Theory aside, here’s what I do to have peace of mind: switch on the Take snapshots of changed text documents on manual save setting, in the General: Saving preference pane. Using manual save is already a bit of a habit for me because I also make use of the Back up with each manual save setting in the Backup preference pane. When I’ve done a chunk of work and I’m happy with the state of everything I’ve worked on in that session, I hit ⌘S and in doing so I get every single file I’ve touched backed up individually with snapshots, as well as the project structure and content as a whole.

There is nothing convoluted about that to my mind—it is in fact precisely the same sort of mechanical action/reaction you get from a single-document based application where when you save a file that’s your last anchor point set. I don’t have to think about these snapshots, I never do, and when I need them they are there.

The only downside to that approach really isn’t much of one in Scrivener 3. In the past it meant a proliferation of hard to clear out snapshots. The snapshots still proliferate of course—that is what we want after all—it’s the clearing of them that is now easier: the Documents ▸ Snapshots ▸ Snapshots Manager feature makes it a simple affair to purge these old automatic snapshots across large groups of documents at once.
.:.
Ioa Petra'ka
“Whole sight, or all the rest is desolation.” —John Fowles

Ia
Ian Stewart
Posts: 7
Joined: Mon Mar 12, 2018 8:32 am
Platform: Mac

Mon Mar 12, 2018 5:16 pm Post

Thank you for your reply AMBERV. Like you I use manual save but have basically switched off automatic backups by using a very long time in the preferences.
I will definitely give this software another try and when some research is completed and checked save a snapshot as something like 'final corrected version'. However MacJournal does allow you to lock a document by using CMD + i and unticking the editable box. Also IAWriter is simpler software of course but does allow locking. I do try to get into the ethos of software I use so will give it another go. (Another thing, I wish you could switch off automatic backups altogether.)

User avatar
AmberV
Posts: 22063
Joined: Sun Jun 18, 2006 4:30 am
Platform: Mac + Linux
Location: Santiago de Compostela, Galiza
Contact:

Mon Mar 12, 2018 5:52 pm Post

We might be using different terminology for backups. I’m referring to the zipped archives of projects that are, by default, created whenever you close a project. It’s another safety net in that if you close with unwanted changes you can go back to the previous state and pull out the desired text from that backed up project, plugging it back into the main one. You can switch that off in the Backup preference pane, but in most cases I would say it’s a better option to switch it off for individual projects, in their respective Backup pane in Project ▸ Project Settings..., particularly if the problem is a few very large projects that take a long time to back up.

Now you seem to be talking about auto-save, which is something else entirely. That’s not a backup as it writes data right back on top of the thing you have open. It’s just like auto-save at the macOS level if you choose to enable it. We don’t have any plans of making a switch for turning that off, it is very rare that anyone really wants to do that, and for those that do, setting “9999” on the idle timer or whatever is surely good enough. It’s a much riskier way of working, and contrary to the design of the software, so we’d rather keep that a somewhat “undocumented hack”.

All right, I see the checkbox in MacJournal now. Such falls right into the lines I drew regarding categories though. You can lock files in DEVONthink Pro, and in EagleFiler you can globally lock down all editing in the viewer pane as opposed to finer grained locking. None of these programs are designed to assemble dozens of chunks of text into one editor however—where entries/records/notes are discrete files really. I think perhaps if anything were to make sense in Scrivener, it would be such a global lockdown of all editing. Kind of odd perhaps for a writing program (never mind a massive job rewriting every widget that is capable of modifying stuff)—but that makes more design sense than fine grained locking.

Also IAWriter is simpler software of course but does allow locking.


I don’t have that software, but it wouldn’t surprise me if IAWriter is merely providing a front end to the ability to lock any file in Finder with the Get Info palette. It’s a rather stripped down plain-text editor more along the lines of TextEdit, and not a database of files. Maybe they do something else, but it wouldn’t make much sense to me to roll a whole new locking mechanism from scratch when the file system already has it built in. Unfortunately that mechanism was never designed for multi-file package formats like Scrivener’s however.
.:.
Ioa Petra'ka
“Whole sight, or all the rest is desolation.” —John Fowles

User avatar
Silverdragon
Posts: 700
Joined: Mon Jul 29, 2013 2:52 pm
Platform: Mac + iOS
Location: Tarzana, California, USA
Contact:

Mon Mar 12, 2018 7:04 pm Post

I've been following the debate here, and would like to add a respectful voice in favour of document locking.

I use a SINGLE project for several volumes of a series. So far I have a novella published, am prepping a short-short story for submission to an anthology, and am working on a full-scale novel with follow-on volumes partly outlined. All different stories, but with the same protagonists and same universe.

If I had a massive scrivening and was doing a global change therein, and had included already published material for some reason (likely inadvertent), I ABSOLUTELY would like a dialog telling me that I had locked 76 files out of 207 and therefore the global change would not happen.

I have taken snapshots, of course, just as you suggest, and could back out. Nonetheless, there is no warning of impending doom, and I might not remember to check by comparing to backup when, say, doing a compile of an omnibus volume.

I understand the fear of tech support nightmare: I was a software QA engineer for many years, and was often called upon to help tech support during release of new or revised software. (I was SO glad it was not my regular job! ) I certainly can respect your decision to avoid it. Nonetheless, in my own workflow, an ability to lock would be wizard.
So you know where I'm coming from:
  • I'm a user, not an L&L employee.
  • Mac Scrivener 3.0.3, MacBook Air 11, MacOS 10.13.6 (High Sierra)
  • IOS Scrivener 1.1.5, iPhone 6s, iPad Air 2, iOS 12.0

User avatar
AmberV
Posts: 22063
Joined: Sun Jun 18, 2006 4:30 am
Platform: Mac + Linux
Location: Santiago de Compostela, Galiza
Contact:

Mon Mar 12, 2018 8:05 pm Post

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:

  1. Select all of the items you intend to bulk replace.
  2. Hit ⇧⌘5 and do a bulk snapshot with title.
  3. 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.
.:.
Ioa Petra'ka
“Whole sight, or all the rest is desolation.” —John Fowles

User avatar
Silverdragon
Posts: 700
Joined: Mon Jul 29, 2013 2:52 pm
Platform: Mac + iOS
Location: Tarzana, California, USA
Contact:

Mon Mar 12, 2018 8:56 pm Post

*sighs* I understand the "this is a deep change to how the entire program is designed to work" thing. And it's just Keith (may he live a thousand years!) to do it on Mac & iOS. And two developers on Windows whose names I have not memorised (my apologies.) For the Mac-centric who might not see the need, there would not only be the Mac version, but changing iOS and Windows to manage locked files, as it implies a project format change. It probably could not be done short of a major revision such as the one we are still in the middle of (Mac 2.x + Windows 1.x -> 3.0.x) with all the rollout issues we have now. I totally get that
  1. Keith is not about to do a feature like this when he's still stomping Mac 3.0.x bugs and maybe considering feature tweaks, and
  2. if I were one of the Windows developers and Keith said "Oh by the way make locking files possible; you can do that without slipping the Windows 3 release, right?" I'd shoot him with a bazooka.

Thanks for some alternative strategies for working with my massive pile of words. ;) I'll re-read your suggestions carefully to see which might work best in my current workflow.

Still, to quote from the movie "Excalibur"—"It is a dream I have." :D (Arthur knew dang well that he was not going to get what he asked.)
So you know where I'm coming from:
  • I'm a user, not an L&L employee.
  • Mac Scrivener 3.0.3, MacBook Air 11, MacOS 10.13.6 (High Sierra)
  • IOS Scrivener 1.1.5, iPhone 6s, iPad Air 2, iOS 12.0

Ia
Ian Stewart
Posts: 7
Joined: Mon Mar 12, 2018 8:32 am
Platform: Mac

Tue Mar 13, 2018 11:00 am Post

I agree with Silverdragon. Scrivener is perfect for research and when I type out quotes/lists/summaries from text books that page is fixed as it is not my creative work but research. The reference library I use does not allow photocopying or photography so I am basically doing manual photocopying (fortunately I'm quite a fast typist).
I used to use Scrivener for poetry, once the poem is finished and carefully checked I don't want any accidental changes. However I will give snapshots another try as it is less inconvenient than using MacJournal for something it wasn't designed for.
Thank you for all your suggestions AMBERV, as I said I think saving just one snapshot and calling it something like Final Version (Checked) would be a good solution. When I need to be certain it hasn't been changed I will just use Roll Back - I have started trying this and it is not as" convoluted" as I originally experienced it. I will reread your posts as there is really good advice there. This is good because as I said Scrivener is almost the perfect software for what I do.

User avatar
AmberV
Posts: 22063
Joined: Sun Jun 18, 2006 4:30 am
Platform: Mac + Linux
Location: Santiago de Compostela, Galiza
Contact:

Wed Mar 14, 2018 1:52 pm Post

Glad to hear it wasn’t all quite as messy as you remembered it being. It’s funny in a way because Scrivener has had two particular tools available to it, the auto-save and snapshot features, long before the concept was terribly popular—so it does do some things differently. With macOS 10.7, Apple introduced a similar mechanism system-wide, but with slightly less control over when a version is made. I find their implementation, although it doesn’t require any awareness to be using it, rather too far over on the side of chaff. If I browse through versions for documents I see micro-edits being preserved as whole slices in the version stack, and finding what I want can mean trawling through dozens of sentence level edits. And well, the less said about the Star Trek interface that blots out the entire computer until you are done with it, the better. :)

I do prefer the more intentional mechanism Scrivener uses. To me, ⌘5 is a bit like ⌘S (and not just in appearance!). I use it whenever I’m about to change course while editing, and I use it when I’m done. I can browse “versions” that were made for human reasons in a comfortable and integrated environment. Make ⌘5 as habitual as saving in Word, or ⇧⌘5 as habitual as using Save As, and you’ll rarely run into cases where a sentence gets lost to an over-aggressive edit.

To summarise our offerings in terms of safety nets:

  • Fully automatic (by default): project backups. Every time you close the whole thing gets backed up, down to label changes and compile settings, let alone text.
  • Automatic snapshots (as an option): triggered whenever you save the whole project.
  • Manual backups: setting aside simply triggering the automatic backup system, manually setting aside a stack of backups in another location provides that same level of human reasoning for having them. The automatic stuff is good—like Time Machine and Versions can be—but a stack of files that isn’t rotated by software and that can be labelled meaningfully is often a life saver. If you accidentally modify an old book that is laying around in the binder for reference, you can pull up the milestone that was created when that book was finalised as a project and drag in as much binder tree as needed to restore it intact.
  • And of course by that same token, manually created snapshots fall into that same realm. You can have a somewhat macOS Versionesque spool of incidental time frames, but unlike macOS you can have labelled milestones thrown into the mix too.

For the stuff we write that we probably won’t want to edit again, that’s all well and good, but for the stuff that we definitely don’t want to edit, ever, try this:

  1. Hit ⌘P from the editor on the text you wish to preserve.
  2. From the print preview, use the “PDF” button to send a copy of the file back to Scrivener.
  3. Maybe copy and paste the original text it came from into the Document Notes for the PDF.

PDF remains searchable, can be annotated simply in Scrivener or more thoroughly in dedicated readers, and is pretty good for copy and paste (though the sidebar Notes copy would probably be preferable for that). And of course a similar approach can be adopted from the start—instead of dragging a .docx into the binder, just open it in LibreOffice or whatever and print it to Scrivener. If something truly is never meant to be touched, why import it as a text file at all?
.:.
Ioa Petra'ka
“Whole sight, or all the rest is desolation.” —John Fowles

Ia
Ian Stewart
Posts: 7
Joined: Mon Mar 12, 2018 8:32 am
Platform: Mac

Wed Mar 14, 2018 3:35 pm Post

AmberV wrote: And of course a similar approach can be adopted from the start—instead of dragging a .docx into the binder, just open it in LibreOffice or whatever and print it to Scrivener. If something truly is never meant to be touched, why import it as a text file at all?

Printing directly to Scrivener is a really good idea, I hadn't thought of that. I have also discovered that a file in the draft folder can also be printed directly to the research folder which is wonderful.
With a snapshot for the final draft and printing for research my concerns are completely allayed and I now use Scrivener as my basic software again for writing and research.
Finally anyone reading my previous posts should be aware my one and only concern with Scrivener was fear of accidentally changing something after several months. This is definitely no longer a concern and I recommend this software without reservation.
(Please note: I have absolutely now connection with L&L whatsoever.)