The idea occurred to me that if a closed Scrivener project were a zipped archive, Word style, then syncing it among machines would become pretty simple: save Scrivener project on a synced folder on machine A, go over to Machine B and see if the latest version is there yet; when it is, open it and start working. Like Word, in this mode Scrivener would need to unzip the zipped version on open and re-zip it on close. Obviously, such a capability would need to be an option rather than a replacement for the current method. You could still get out of sync if you didn’t close a Scrivener project before opening it elsewhere, but I believe that’s the only real risk. Advantage: no special API would be needed, since Scrivener would only be unzipping/opening and zipping/writing one file per project. Also, Scrivener could periodically check to see if the zipfile’s date or size has changed unexpectedly, as a crude way to detect a simultaneous open+close of a project—in that case, it could issue a warning and, on close, write to a different zip file.
The difference between Scrivener and Word is that a Word document is all loaded into memory when opened; a Scrivener project is potentially 100s of files but only the ones necessary for what you are actually working on are loaded into memory. If a zipped format was used, what would happen with a 100GB project? There are those whose projects are that big.
Well, I use the same shared cloud folder for my zip backups for both machine A and B. On machine A, i use the File > Backup now function to backup the full project as one file to my designated cloud folder (Google Drive). Now on computer B I open the shared cloud folder and go to my saved backup folder and use the Date modified column to assure I am picking the most recent backup.
This is a pain, but the safest way. I move the current Scrivener version of Project X to my desktop on computer B, and unzip the latest backup of Project X from computer A into the Project Folder on Computer B. Once I know it is working, I delete the old Project Folder.
I have never had a problem this way. Though note when first open computer B may need to let it sync to the cloud folder, before the latest backups will be available to unzip.
I’m pretty sure that in a docx project, there are many files other than the main text, and not all need to be loaded. But from Scrivener’s point of view, once it unzipped the “project.scrivz” file into a hidden .project.scriv bundle, nothing would be changed. Normal work with many files in a bundle would ensue until closing, at which point project.scrivz would be overwritten and .project.scriv removed.
It might take a beat or two more to open or close a zipped Scrivener project, and would use more disk space while the project is open, but other than that, it would just be good ol’ Scrivener.
It is not unusual for Scrivener projects to be well into the hundreds of megabytes, and gigabyte projects are not unknown. So it could definitely take more than a “beat or two” to open or close the project.
Possibly worse, every project-saving operation, including syncing, would have to contend with the entire project folder, plus the overhead of zipping/unzipping. Forcing people to resync an entire GB-sized project because they added one line would be quite likely to send hardware flying through the air.
The option has been discussed before, and we’ve decided it’s not workable at the Scrivener-wide level. As the “alternative method” describes, though, we can certainly accommodate people who choose to work this way.
To each their own. But this logic means that the possibility of an unusually large project means that people with more typical projects can’t have this feature. My last big project is a measly 253 Mbytes. The bundle took about 5-6 seconds to zip on my MacBook Pro. To me, if I wanted to use this method to sync among my devices, that amount of time or even several times more would totally be worth it, if it was in exchange for a simple and bulletproof way to work on multiple devices.
But never mind. This Nano, for a change, I decided to use Ulysses, which syncs out of the box. It will be interesting to see how much this impedes my writing efforts.
Note that it’s possible to automate much of the process. Either Scrivener’s automatic backups or the File → Backup → Backup To command can be used to create a time-stamped backup in a synchronized location.
Using Ulysses only lasted for a week and a half or so, until I had written enough to want to be able to export a few chapters to look at. At that point, I discovered that Ulysses has no way to auto-number chapters. That, plus a couple of other klunkinesses drove me right back to Scrivener. Since I had to choose between smooth use from any device versus an actual full-featured writing program, I definitely went with the latter. I can live with doing it all on my Mac.
I did make an awesome discovery, though. If you export the current version of your project as a pdf file and save it in iCloud, then you can open it on your iPad and mark it up with your Apple Pencil. This is basically a 21st Century way to do what everyone had to do back in the day: print out a copy, mark it up, type in the changes. Sure, it would be nice to have synchronization capability, but I can live with marking up a pdf if I get an idea or a moment to edit when I’m away from my computer. For actual writing, I could do that in Notes and paste the result into Scrivener.
I like your process of printing a draft to PDF and reading/editing that … either on iPad or paper copy. That’s how I mostly do it and always do it that way when editing/reviewing another author’s work.
That being said, I still enjoy the benefits of using Scrivener’s well supported way of using Dropbox to sync between macOS and iOS versions of Scrivener. Simple, it works, and free of any futzing around.
I do review/edit/write of my own stuff on the iPad when the urge strikes, or “out and about”. It’s a great compliment to desktop version of Scrivener.