Project version history – another hierarchy for snapshots

Scrivener Wish List
1

Hi!
I’ve scoured the search but couldn’t exactly find what I was looking for. I’m gonna try to explain why I would vouch for another hierarchy-level for snapshots, as in: saving the entire project in the state its in right now, then proceeding to edit etc.

Why?
I’ve written multiple novels in Scrivener and always found myself in Word after the first complete draft. I’d format it etc. and then save it as “Revision 1”, work over it and then save that as “Revision 2” etc. I’d never go back in Scrivener, which is a shame.
Right now I’m trying to keep the workflow in Scrivener, but it’s hard. For example, I’ve decided between “Publisheable and in itself coherent version 1” that the backstory and age of a character should be different. This led to changes of multiple documents. I snapshotted each of those documents and typed in “State of Version 1” and then made the changes to preserve the previous versions, but as I see it there’s no simple way for me to tell scrivener “Hey, could you just export Version 1”.

Here’s my suggestion
There’s a button / functionality that basically makes a certain entry visible in the Snapshot menu (Like a red divider line, named “Version 1” so one can see when the project was deemed to be at a certain level where it could be published. Snapshots are rather Version 1.xx-level changes, if that makes sense.

Additionally, there’s some sort of comment of which state exactly this version represents, e.g. “before changing Charakter’s backstory”

And, for the grand finale: in Export, there’s an option to “export a project version other than the current”. This basically takes the export selection and checks whether a document existed at the time of the version save (if not, it’s simply omitted) and if it did exist, it exports the then current version

Why don’t you just save the entire project?

  • I’ve tried that and it doesn’t really work for me for various reasons. one: i’m dragging / duplicating research files and background info just because i’m doing revisions.
  • two: it’s counter-intuitive. It’s still the same project, it’s still the same documents if you look at it. Having multiple stages makes it a hassle / confusing to look for documents (which e.g. I’ve deleted to save space).
  • three: it rises room for error. If I’m looking through three different project files looking for an old document and in the meantime think I caught a spelling error or something and change it, chances that it’s the non-active version are at least 20%.

One and three can be attributed to, well, me being not a streamlined brain-owner, but two is what bugs me most. Like yeah I could just export Word-Documents of the big revisions, but what if I wanna export those as PDF / epub from Scrivener again to see them side by side? That’s the cool thing about revisions, after all.

I hope I’ve explained it throughly enough to understand how it’d look implemented and work and why it’d be of a huge benefit for my workflow. Suggestions and answers are very welcome: it might just be a me-problem.

Love,
Ally xx

1 Like
2

What about duplicating the Draft folder within the Binder and naming the duplicate Version 1? Add whatever notes you want to the top level folder for the duplicate.

Katherine

2 Likes
3

I do also think that duplicating the Draft folder in the binder, renaming it to “Book Name - Rev1” (or whatever) and then making your revisions inline in the Draft is going to be the simplest approach. It’s fundamentally the same kind of thing you’re doing in Word, when you use Save As and have a sequence of doc files for your revision—but like you say it avoids the whole issue of having different projects for no reason other than starting a new revision sweep.

I agree with you, it’s a messy way to work in general, especially when Scrivener has such a wide variety of tools for handling problems like this within the confines of one project. I’d say a vast percentage of the “help, Scrivener loaded an ancient version of my project!” questions you see around here are people accidentally loading old copies of the project.

When it comes to compilation, and thus organising things, there are two approaches you could take:

  1. If compiling old revisions is something you only do now and then, the most straight-forward approach is to simply swap the contents of the Draft folder with the revision folder you’re wanting to compile. You don’t need any kind of special setup for that, but it does involve a little more work each time you switch.

  2. If you frequently switch, then spending a little extra effort up front will be more efficient in the long run. For this approach, the idea is to put each revision into a subfolder beneath Draft, and hot-swap between them when you compile.

    Read more... 
    Draft/
	Revision 1/
		Chapter A
		Chapter B
		...
	Revision 2/
		Etc.
    1. At this point you should check the Section Types pane, in Project ▸ Project Settings..., and make sure everything is still lined up right with the new level of depth being added. So long as “Chapter A” remains what is was before this tweak (and any sections/subsections/etc. below that point), everything will be fine when you compile.
    2. Once you’ve got that set up, go into Compile, and in the Contents tab on the right, select the current master revision folder at the very top, ticking the Treat compile group as complete manuscript checkbox. Once you’ve done that, hold down the Option key and click the Save button, which will appear.
    3. The last thing you may want to tweak, if you use project goals, is to make sure that the option is set to only count the current compile group (otherwise it will count everything in every revision).

    So yeah, a little more setup—but now whenever you want to switch revisions, it’s a simple matter of changing that one dropdown in the compile window.

Now as for Snapshots, there is no way to make them work quite like you want in an efficient manner. Probably the best you could do is open up the Documents ▸ Snapshots ▸ Snapshots Manager window, search for your marker, and go through one by one clicking the “Roll Back” button. It’s hardly even worth considering in my opinion. Snapshots are better for keeping individual revisions safe, they aren’t really designed to orchestrate compiling different “editions” of the project. There are better tools for that throughout the software (the above method is only one of them).

Additionally, there’s some sort of comment of which state exactly this version represents, e.g. “before changing Charakter’s backstory”

The multi-folder approach described above (however you organise them) has a natural way of doing that of course. Since each revision is in its own folder, you can add all manner of annotation, synopsis and notes to the folder itself.

1 Like
4

Ally,

Since your specially version-snapshotted version 1 would be static anyway (typos and all), you might just as well compile your manuscript at each version-mark moment and keep the output. You would, I think, achieve the same end.

gr

p.s. For my own part, anything that tempts me to multiply and maintain alternate narrative possibilities is something I try to avoid.

5

Thank you so much for your reply – that seems sensible and the keep it simple, stupid approach.
I think I avoided it so far because I was scared the scriv-project would double in size – I had one project that was huge for no reason (except: i had one or two bigger photos in the references, which i then deleted and emptied out the trash, but the project remained huge) and took FOREVER to sync to my dropbox when it was saved. Probably why I was hesistant to do that, but as it’s only rtf-files, it shouldn’t hurt a lot.

6

Thanks for your reply! As said, I really like this idea and it makes sense (and it’s much more convenient than comparing word or pdf documents, believe me :smiley: – thanks to the split editor)
Thanks for describing the second option in such detail – it sounds interesting, I’ll look into that. I don’t switch a lot, I just wanna keep old revisions for the sake of really being able to send “Rev 1” and “Rev 2” to beta-readers and asking them whether they miss this one story-arc being executed etc.

Now as for Snapshots, there is no way to make them work quite like you want in an efficient manner. Probably the best you could do is open up the Documents ▸ Snapshots ▸ Snapshots Manager window, search for your marker, and go through one by one clicking the “Roll Back” button.

I think I explained my idea a bit clumsily – I know that with the current features / without the whole option of just “export project at XY revision cut” the idea is worth zilch as you’d have to roll back stuff manually, export it etc. I just thought I’d be neat to have it as it would save the project from growing ~ 100 documents + their respective snapshots per revision as copying the manuscript folder does. RTF-docs aren’t big, yeah, but it still seemed like a clever solution to me if you’d give the authors that option.

1 Like
7

[quote=“gr, post:4, topic:119634, full:true”]
Ally,

Since your specially version-snapshotted version 1 would be static anyway (typos and all), you might just as well compile your manuscript at each version-mark moment and keep the output. You would, I think, achieve the same end.[/quote]

Thank you for your reply – I actually keep pdfs / epubs of the big revisions, but still missed having this state in Scrivener to just whip it up.

[quote=“gr, post:4, topic:119634, full:true”]
p.s. For my own part, anything that tempts me to multiply and maintain alternate narrative possibilities is something I try to avoid.[/quote]

I fully agree with you that decisions & sticking to them is crucial; I’m mostly having this whole revision dilemma when it comes to “is sideplot A or B more effective”. I’ll usually execute both of 'em to see how they perform, and because both just are fun, but in the end one has to go. So usually between original draft + revision 1 I’ll reduce the second one. Or I’ll edit out some bits and pieces that are unnecessary but I still love them. I appreciate the final thing for it’s condensed feeling and being beautifully edited / poignant, but the silly emotional author in me still loves the version with more backstory information and self-indulgent scenes.

8

You’re welcome! I hope you find a good solution to this problem, because personally I find Scrivener such a powerful editing and revision management environment—better surely than its performance in the initial writing phase (because let’s be honest, all you need for that is a keyboard and something that remembers which keys we press). I do know a lot of people prefer going to other software at a certain point to edit, but I’ve yet to find anything that makes grappling with the big picture easier.

I think I explained my idea a bit clumsily – I know that with the current features / without the whole option of just “export project at XY revision cut” the idea is worth zilch as you’d have to roll back stuff manually, export it etc.

To the contrary, I explained myself poorly. :slight_smile: I did understand that you meant this as a suggestion for making Snapshots better for this purpose. I was intending to underscore that we see other approaches as being superior tools for the job, rather than a somewhat buried stack of “hard saves” that isn’t fully integrated with the binder. I guess the thought there being that Snapshots naturally hide the old revision beneath the item in the binder, but if a revision is something you want to have a whole picture of, like you do, then having the whole text in its preserved state as an outline you can load up in splits, and annotated and anything else you might want to do with it, will be so much more beneficial to you.

So if we did wish to make improvements that would benefit this style of working, it would probably be to those areas we’ve already invested time into, perhaps to make them a little more obvious.

I definitely do see your point, in that Snapshots is already there as a feature, and with a few tweaks we could make it work differently—I just don’t see that as a direction we’d want to take snapshots though.

Snapshots & Duplications: speaking on the storage burden of duplication, I should add one important thing to be aware of. This may in fact be what you ran into before, but mixing heavy snapshot usage with full-draft duplications can cause a lot of files to be created. When you duplicate an item you aren’t just copying its RTF file twice, but all of its snapshot RTF files. If on average every item has 8 or so snapshots, and you duplicate a typical novel size outline (let’s say 25 chapters with an average of three scenes per) of 75 total outline items—that’s roughly six hundred RTF files being created. While that may not take up a lot of physical space, that is going to really slow Dropbox down.

So if you do use a lot of snapshots—consider that, and keep the Snapshots Manager in mind. You may wish to mass cull the snapshots from the current revision, retaining them only in the old revision. Then snapshots become a per-revision thing rather than ending up with hundreds of redundant copies.

Hmm, and now you’ve got me thinking about how duplication could be made more efficient. Like what if duplication only mirrored the binder items themselves, rather than copying what’s on the disk—until either one of the copies is edited. To you as the user it would appear 100% like a normal duplication for that reason. Once you edit the data it forks and is stored separately. But that new file is only created if you need it. Thus, you can create a copy of a 500 binder item book outline and only edit 15 items within it, really only duplicating 15 items on the disk but visually showing them in context with the other 485.

1 Like
9

In enterprise storage this is known as “copy on write,” and it’s how high-end file storage solutions could keep tons of snapshots. Every time they need to write to disk, instead of writing back to the same block, they simply write out the new block to a fresh unused block on disk. Then they keep track of previously used blocks as part of the snapshot mechanism, and once a snapshot expires that block becomes zeroed out. It helps improve storage performance plus gives wonderful snapshot resiliency across an entire volume.

It would be really interesting to see if something like that could help make Scrivener snapshots more usable on a project-wide basis, rather than per-document.

1 Like
10

Ya, and I think ultimately where the idea would be most feasible is at a much lower level like what you’re talking about, rather than it being something that is orchestrated at the binder->disk level. The main issue with a program like Scrivener, and an idea like that, is that what we think of in the user space as “a file” is more often several files. The index card is a .txt file, the main editor is .rtf, the Notes in the inspector is another .rtf, style usage generates another file, footnotes go into yet another one… and then you’ve got snapshots. So the notion of forking all of that the moment any one component is changed is more complicated, and could cause visible performance issues. If system is physically duplicating 15 files at the moment you delete one word in an index card, you’d notice the lag.

In the end, there may be some less complex way to solve what is at a higher level the simple user space problem: I want to see “Revision 3” with full narrative order as I wrote it for Rev 2, and then be able to edit one subplot that might involve changing 15 scenes across 8 chapters. That is what is wanted—what is the best way to handle that on the disk without running into the 600-file problem.

2 Likes
11

Yeah, the reason why copy-on-write works for disk file systems is that you’re always writing in blocks, so it’s a fixed value (or multiple thereof) and you’re taking advantage of the physics of spinning platters (or their emulations for modern solid state drives). Once you start writing variable length data files…all bets are off.

12

That is, in fact, what I was concerned with. Thank you for clarifying and also stating that this is not where you wanna take scrivener – i understand that completely. Your bit within the end is very interesting:

This is somewhat where i was going with the “just a marker of when big revision happened” in the Snapshot menu. Like, just simply duplicating a file is not necessary if a document doesn’t change at all between v1 and v3. But the snapshot menu would display some sort of line “Revision State 1” “Revision State 2” and “Revision State 3” and for more user-friendly viewing, have 3 Revision states in the binder that of course refer all to the same doc. That approach would eliminate the multitude of files, if i’m not mistaken.

1 Like
13

I get that, but the main issue is that snapshots don’t really solve the full problem, as they are currently, to a very deep level, designed. They are single-node backups that have no awareness of the overall narrative structure like the outline does—and I would say to a large-scale narrative level revision, that structure is almost as important as the text you put into it.

So even if there was a marker of some sort, and snapshots were automatically created as you changed text, it wouldn’t preserve shifting scenes around or seeing how things flow without a chapter or two. That is where they would require a fundamental redesign, and it would be a pretty complicated problem to solve at a technological level.

The problems of snapshot proliferation within the outline aside, duplicating the entire draft is fundamentally no different than using Save As in Word on an entire manuscript. Either way all of that text is being duplicated, whether it is stored in micro-files in an outline or all in one huge file.

1 Like
14

To be fair, I’d be willing to work around the given example with collections, that works fairly well, but I get what you mean. As for the way it’d be implemented, I’m aware of my own shortcomings when it comes to programming – I simply gave the suggestion because I detest when people scream they want something but have given no thought to how it could look when it’s done, haha.
I’d be very happy if my idea gives valuable input, no matter whether it’s scrapped in the end as being unfeasible, not demanded by enough users, or actually implemented but in different form as described. :slight_smile:

1 Like