I need to work on two laptops…and I can’t ever open my Scrivener file on both. I have to choose, and that’s with the cloud use (Dropbox). I know that topic is here already, but none of the suggestions have conquered this for me. Kind suggestions, please? Work arounds?
Scrivener projects are designed NOT TO be editable (opened) in two places at once.
You won’t find a way.
If you really want to do this, clone your project with an explicit name, and be prepared to be the manager (you’ll have to manually keep one version up to date with whatever you’ll have done in the second one). ⮘ I, personally, wouldn’t want to have anything to do with this. I’d much prefer to carry around my desktop, screen, keyboard – the whole shebang + cables and powerbar – rather than to mess around like this.
My best advice, since you’ll likely not really be working on both computers at once (I picture you wanting to have it accessible in two locations, two rooms in your house, or something like that), would be to have a single version of your project on a USB 3.x thumbdrive. Develop the habit of having it follow you around. Back-up plenty, for the day you’ll misplace it. (You won’t gain much, using a thumbdrive ; except that you won’t be able to have left the project open on one computer, only to find yourself unable to open the said project on the other one. The USB key will force you to make the transition conscious. – The other option is to still use a cloud service, and set Scrivener to automatically close the project on its own. But in your case the inactivity period might be too short to be functional. ??)
2 Likes
Two amazingly helpful suggestions. Thank you, thank you. Even if I don’t leave it open on one laptop (and for sure sometimes I do…its a book)…I get that “older version” error code.
1 Like
That’s why the USB key is a good idea. As I said, you wouldn’t gain anything on the technical side (even more, it gives you something that you can lose…) [⮘EDIT – The USB key is an immediate transition, unlike for a cloud based project.], but, BUT, it makes it a conscious transition. And so you’ll close the project, then pull out your USB thumbdrive.
That’s your cloud service that haven’t updated yet.
Honestly, if you want it functional, use a thumbdrive. (Backup as if you plan on losing it.)
How far apart in traveling time are your two computers from one another?
. . . . . . . .
It just occured to me: if both computers are connected to the same router, you might want to experiment with a remote viewer. Something like PC-Anywhere for Windows. (?) I have never tried it, but it might work. You’d keep the project open on a single computer (always the same), and work on the project on that one computer, remotely, from the second.
2 Likes
If I clean up my habits, it would be two or three hours. I had just decided I would only use one laptop to complete the book I’m writing, completely giving in to the tech fail.
Ordered a thumb drive…now to plan for backup
Is that how far apart your two computers are? (If so, keep it simple, use auto-quit.)
That’s a contradiction. Please expand.
1 Like
Regarding the two laptop usage, started to wonder if Scrivener can use Git(hub) as a backup storage.
1 Like
Sorry, I meant that yes I’ve order the thumb drive. Now I need to get into the practice of backing up lots, and the new habit.
As already commented, you cannot have a project open on two devices at the same time.
The Dropbox sync process is solid and works just fine. There’s a full discussion on setup and process. Just make certain you have the Dropbox folder selected to make the project available offline.
You can use other cloud services (but NOT Google Drive) with care if iOS is not in the mix.
Yes, you can use a USB stick, but IMHO that’s just extra faffing around.
2 Likes
This would be a Bad Idea.
Yes, you can, but Git will see the content of the Scrivener file (which is a package, containing lots of small files). The danger here is that if you modify one of those files (rollback, or merge, or whatever), it’ll desynchronise with the config files that glue everything together. It will break. I definitely do not recommend this.
Example (because I wanted to check what happened to packaged files). This is the .scriv file for one of my novels dropped into Git. It gets exploded to almost 200 files…
2 Likes
This is all probably well off topic for what the OP is intending to do, but to clarify a few points regard CVS (git or whatever):
-
All Scrivener projects are folders with lots of files and folders in them, and outside of the Mac GUI that is what they will always look like. Any Windows/Linux user can attest to that, or anyone that uses the command-line on a Mac.
So by extension, any sync service is going to be interfacing with a project at this level of independent files, even those that pretend otherwise like iCloud. They are all going to have to keep everything internal to the project on the same page.
By and large this shouldn’t matter, as any sync engine or CVS is going to be keeping the whole up to date together, just as your disk would when you edit it with Scrivener, or make a copy of it to another disk.
-
So if anything a system like Git, if you know how to use it effectively, is safer and better to use than a mainstream sync tool which handles most of these matters in a semi-automatic fashion that may or may not be to your advantage. The only real user-side difference between the two is that a system like Git would let you know exactly what conflicted inside two different files and offer to help you merge them, whereas a sync tool won’t bother, will just duplicate the internal files, and leave it up to you to merge them yourself. The conflict itself may not even be in the content, but that’s something you have to figure out on your own.
Github itself is fine, I would not classify it as a bad idea. We use it ourselves for the Windows tutorial project, and I use it personally with a few of my projects. I’ve never run into any issues with it, whereas more standard sync services have caused more issues for me (to the point that I don’t use them for live projects).
You are right though that in most cases you wouldn’t want to manually merge a branch or do anything wild with it like that (and if anyone reading this has no idea what those words mean, then just stick with mainstream sync 
). You could, especially if you know what you are doing, but I would guess it would more often be more effort than is worth the result. It would be easier to just Save As an experimental fork locally, and if you like what you did with it, use Scrivener’s project import & merge feature (on a Mac). Let it handle that complicated process for you, rather than trying to use CVS tools and burying yourself in Scrivener project format particulars.
But if you are very familiar with these tools, and largely use it as a “better sync”, treating your usage of it roughly like you would treat sync—as I say it’s probably all around a better solution since it gives you more detailed data on what went wrong, if things do go wrong. Certainly, if one is using it as @PatchworkCat suggested, as a backup that only gets updated from a local copy, I can see no technical reason for why that would be problematic. Most of the issues with CVS are human-created issues of expecting the internal components of a file format to be as forkable as a code base. It would be just as difficult to fork and merge a DOCX file you’ve unzipped and hosted on Github. That’s all just more down to how file formats tend to excessively self-reference and require a lot of knowledge of how that is done to properly repair them.
The only flaw we are aware of with Github is cross-platform related, and easily solved with configuration to suppress automatic Win/UNIX line ending conversion.
2 Likes