Snapshots after merging

Scrivener Scrivener for Windows
1

Hi. When documents have snapshots, and those documents are merged, their snapshots are retained in the resulting merged document. But this does not seem to work when the top document is a parent doc, and the others are subdocs of it.

I first noticed this when it happened unexpectedly. And then confirmed the behavior a couple of times.

Is that how it’s supposed to work? The manual says snapshot lists are combined, and that is indeed how it works, except as noted. seems odd that a parent child relationship should make a difference. (The parent was a document, not a folder. Would that matter? Haven’t tested.)

Thank you!

2

I confirm : after testing, snapshots from the child documents were lost.

→ Although I have to say, after further testing, that it somewhat seems to be an issue (on my end) with snapshot having the same timestamp. Which would eventually be as equally problematic, since I use the auto-snapshot on manual save feature…

Will do some more testing with snapshots at different time intervals.
→ Definitely an issue with snapshots having the same timestamp… couldn’t reproduce the issue this time, having snapshots taken minutes apart.

Not sure if this should be called a bug, but it should definitely be fixed imo. (It is kind of scary.)

I created 3 documents.
Then I edited all three.
Then manually saved my project (thus creating a snapshot for all three docs).
Went back to doc #2 → renamed the snapshot “2”.
Did the same with doc #3 → renamed the snapshot “3”.
I deleted the snapshot from doc #1. (To make room.)
(Note that both snapshot 2 and 3 are of the exact date and time.)
After merging all three documents, snapshot “3” was lost. Only the snapshot of the up most document in my binder (between doc 2 and doc 3 – so snapshot “2”) survived the merge.

If the snapshots are taken minutes apart, no problem then.

→ After further testing, this issue has nothing to do with a parent-child relationship between documents. (Same results with non-nested documents.)
→ Same result again with folders. (Whether docs are converted to folder or not makes no difference.)

→ Same test again, but this time making manual snapshots (within the same minute) : no issue this time.
Issue seems to manifest itself only for snapshots related to the auto-snapshot on manual save feature. (In other words : for snapshots having been automatically created on the same manual save of the project.)
Issue is probably due to the snapshots having the same timestamp down to the second.

@Mad_Girl_Disease How were your snapshots generated ? Are you using the auto-snapshot on manual save feature ?

3

Another reason I don’t sing the praises of the snapshot feature (or use it). When I want to make major edits to a chapter, I duplicate the chapter (one step for the folder, its children, and attached metadata). I can give the original a distinctive name, mark it not to compile, split the Editor and view it side-by-side (or up-down) with the new version, etc. Snapshots don’t preserve children or any metadata, two of Scrivener’s most important features.

4

Thanks, Vincent_Vincent for investigating.

I was not using any of the auto-snapshot features. Timestamps wouldn’t have been a factor – and I would think that Scrivener is capable of indexing distinct snaps even when they are presented to us in a list with the same name and timestamp.

These were all manual snapshots I made ahead of a series of document merges. I had even tested before, to confirm that it would work as expected. Notes and Synopses, too. Those two seem ok. But I had not tested for a parent-child issue. Not a problem. They were just cautionary backups, and I’d already done a project bak.

Drmajorbob, I take a similar approach with using document Notes. Notes are a great feature in concept, but I find them not quite worth it as they are implemented through the inspector panel. I prefer to keep notes and similar adjunct files in a separate child doc, and view them in a separate full editor. And opening and closing the inspector can be too disruptive to editor scroll positions – as can opening/closing a second editor, but at least an editor is a fully functional window. Might be different were I using a second monitor. Or if the inspector floated.

Also, Notes don’t zoom, leaving text too large in the narrow panel. Also, when I make the scratchpad font readable, it makes the Notes font huge. As I understand it, Scratchpad and Notes share font settings, but one or the other of them is either too large or too small.

1 Like
5

@Mad_Girl_Disease
So, there are two issues here : yours (which I couldn’t then reproduce) and the one related to snapshots with identical timestamps that investigating your issue revealed (and which I more and more see as a big problem ; I ain’t risking any merge of documents until it is fixed – I rely too much on snapshots to gamble it).

So would I, but obviously it doesn’t.

7

Okay, I have managed to reproduce the listed issues and have filed priority tickets for the two. It looks like the parent+child issue requires the parent to have both text and snapshots, in order to safely merge. If the parent has text but no snapshot, a snapshot and no text, or neither, then child item snapshots will be lost.

@Mad_Girl_Disease: I prefer to keep notes and similar adjunct files in a separate child doc, and view them in a separate full editor. And opening and closing the inspector can be too disruptive to editor scroll positions…

I’m a big fan of using the outline to handle notes as well as output material, making liberal use of that Include in compile checkbox. That said, I also love snapshots, use them extensively, and really do not understand why anyone would want to litter their binder with revisions that you can’t directly compare. But Scrivener allows so many different ways of handling these ways of working, there really is no wrong way.

Document Notes—I use them, but not a lot. The main thing I use it for is to keep a “change log”, and to drag over text I want to delete so I can easily bring it back if needed (though I also use inline annotations for that purpose about as much).

Also, Notes don’t zoom, leaving text too large in the narrow panel.

The ability to zoom it to whatever you want on the fly is a missing implementation, but you can change the default font size in the Editing: Formatting settings tab. The other thing to know of is that you can set the default zoom, which has an impact whenever opening a project, with the Default text zoom setting in the Formatting: Options tab.

As to your final comment on the inspector, it’s a shame they have not yet fixed that issue. The new design was supposed to handle the two sidebars, binder and inspector, as additions to the window width rather than cutting into the window width—meaning the content area would always stay the same width (so long as it is possible to do so, maximised windows of course would act the way they always have). There would be an option to turn that off for those that don’t like it.

2 Likes
8

Thank you, AmberV for the follow-up on this!

1 Like
9

Scrivener version 3.1.2 (Oct 18 2022) – Changelog

image
image796×96 7.67 KB

This works A1

image
image825×49 8.05 KB

This doesn’t (it is better than it was, but still somewhat buggy). Merging a parent and two siblings, I ended up with two snapshots in the resulting single document :
One snapshot that merged the content of the parent and last document’s initial snapshot;
and one with only the content of the middle document.
Both snapshots with what appears to be identical timestamps.

[Edit] After trying a few variations of editor content and snapshots/no snapshots at the moment of merging, I get all sorts of (seemingly random) results. Can’t quite wrap my head around it.
Beside that, I couldn’t reproduce the two snapshots after merge mishap I mentioned above. Seems like it happened once and that’s it.

So perhaps in the end it is doing what it is supposed to; and it is only me who needs to get used to it. (?)

Despite that, I think overall it is a great improvement. Especially the part where you don’t lose snapshots taken via the link to manual save function (which snapshots inevitably have the same timestamp) by merging documents. Where it had made it a no-go to temporarily split a document, it is now a safe approach. :slight_smile:

10

As always, it would help to know what “random” means specifically, as in how to get to that point and what the expectation/result difference was. It all seems to be working for me, but I’m just running the same tests I built for it back when we fixed it.

11

I ran a couple more tests this morning and it seems to be fine.
I think that what seemed off to me yesterday is that I somewhat would have expected that if merging documents when the parent one has no snapshot of its own to merge, it would still be added to the resulting snapshot. Which, on second thought, would simply make no sense in most situations. So for that, nevermind, it’s all good.
The only other thing is what I described earlier, where I ended up with two snapshots instead of one. But I can’t reproduce. (Of course, as I was only enthusiastically trying the new feature and not really testing anything, I didn’t document. Lets agree that if nobody encounters such in the future, it was only user error on my end.)

12

Yeah, you should only be getting multiple snapshots if the times are different (which is down to the second, a level of granularity the snapshot viewer does not show). For cases where they are all the same, the colliding snapshots are merged in the same order as the items they came from and thus only produce one snapshot (for that collision, there still may be others).

13

Well, it might not look like much, but this is an awesome improvement.
The impact on my workflow can only be greatly positive.