Sharing a project via Syncthing

I’m about start a joint project, looking for the simplest way to sync our work. Me on Win, he’s on Mac.

I’ve installed Synching, which is a beautifully simple way to keep a folder on different computers perfectly aligned…BUT…

It occurs to me we’ll probably get file contention issues if we have the project open at the same time. The solution, I think, is we agree who has it open at any given time: if he’s working on it, I close it; or he closes it when I want it.

That should be okay, I think. Has anybody tried this, any issues before we try?

PS Not for project backups.

Thanks.

Edit - summary if you don’t want to read the scree below.

  1. Giving SyncThing the heave-ho.
    In theory, great. In practice, a techo play thing stuffed with magic steps and undecipherable error messages. In a past life I was a hardcore developer - assembly language and operating system intestines. So I can stomach a bit of farnarkling, but only when it gets a result, and my writing partner will bludgeon me to death if it’s anything more complicated than toothpick.

  2. Give Dropbox a red hot go. Seems to work fine for other people.

  3. Test thorougly before getting too deep.

  4. Read this carefully (thanks for the tip) Using Scrivener with Cloud-Sync Services / Cloud Syncing / Knowledge Base - Literature and Latte Support

  5. As per those tips, be absolutely sure both writers understand when it’s safe to edit a project. Set up an independent backup regime.

  6. Drink only good quality beer. Or coffee, tea, wine, whisky…

Please read our article on best practices, which is here:

1 Like

Excellent, thanks. As I suspected, all very logical and never open the same project on more than one computer at a time.

I will of course do a trial run, but confident we’re good to go.

2 Likes

Best of luck with your joint writing project.

Also a must is to allow time for the sync service to complete the upload and download. You want to avoid incomplete syncs before setting out to open the project in Scrivener.

1 Like

As someone who has been doing this for over 10 years, a further bit of advice: both of you set Scrivener to back up the project on Open and Close, so that you each have a record of how your collaborator left it and how you left it for your collaborator. That way, If either of you encounters a problem, you can go back to the project as it was at the beginning of the session, and you also retain a record of what you contributed during the session.

:slight_smile:
Mark

3 Likes

Definitely. 99% changes will be a few lines of text, so syncing will be almost instant. And if I try to open the project while he has it open, Scriv should give me an ‘in-use’ warning.

The thing to watch will be when I’m on the road, offline. That means we need to signal who currently owns the file. A manually method is obvious, but I’d MUCH prefer failsafe automation of some sort.

In a former life my professional day job was systems change control, so this is familiar turf, but I don’t know the best solution here.

If one person only edits a file, my guess is it wouldn’t matter because that file would re-sync. But if they add, delete or rename it, the project header file might be corrupted.

Thanks again for your help.

If it were me, once I saw that sync “up” to the third party sync service was complete, I would send a text message (or email) to colleague to say “sync to [whatever]” has completed and ready for you to sync down and do your writing. I’ll not make any changes until I hear from you.". I’d expect a reciprocal message back when the colleague finished their sync “up”.

1 Like

Willco, thanks.

Could do. Another option is to insert a non-printing file at the top of the project containing one of three values:

ROD
DAVID (the other author)
FREE

Check this before starting an edit session, if it says DAVID, don’t change anything.
Else, set it to ROD, then back to FREE when done.

I’m pretty sure if David has it open (and I’m online), Scriv will warn me the file is in use, but let me open it anyway.

Dunno if this is best until we try.

Based on my understanding of how in macOS Dropbox works and how Scrivener works with files in the local macOS Dropbox folder I wouldn’t be so sure about that. You are not really “online” with anything. Maybe it would work, but I’m not so sure it would be sufficiently reliable. Give it good try and stress test the heck out of your idea before relying on it. And best for both of you to be sure you have Scrivener automatic backups running and store them in a secure backup location (not Dropbox sync folder).

1 Like

Second thoughts, Scriv project locking should be enough to warn when the file is in use.

We’re planning to use Syncthing, not Dropbox. Anyway, your point is still valid and this definitely needs stress testing.

As far as I know, SyncThing on a Mac does not use Apple’s infrastructure for smart sync (what is referred to as “File Provider”), as Dropbox, OneDrive, iCloud and some others do. This form of smart/on-demand/deleted-until-manually-downloaded form of “sync” is inherently partial and can cause a wide array of problems when used with software that manages data across multiple files.

Anything that actually synchronises two folders together, without compromise, is going to be inherently more reliable and safer to use. That definitely doesn’t mean there is no need to do a little stress testing, of course, but that you probably won’t be running into the issues like the lock file not being downloaded because your cloud service feels you don’t actually want all of the files that have updated off-machine.

To that end, here is a service checklist I developed that specifically goes over the kinds of things you would want to test, against a program like Scrivener, that are common or theoretical weak points with sync.

You might also want to check out the compatibility FAQ article since you mention Mac/Win collaboration.

Lastly, an option not available to Windows users directly (yet), but indirectly, is the prospect of parallel collaboration. This notion of having to “hot potato” a “single” project and work around schedules and all of that is, in my opinion, not the most convenient and easy way to collaborate with Scrivener users. It might have been a decade ago, but since then the ability to merge projects together has been a thing. That means, in essence, everyone involved (this method scales beyond two) can work on their own optimal schedules, on completely independent copies of the project, without anyone having to spend hours piecing edits back together. We do the hard work for you, with a kind of “sync” that happens inside the project itself.

If you’re working that way, then your SyncThing folder becomes a way of producing copies of the project for merging, and the complexity of its usage can be reduced by pointing the project’s individual automatic backup folder to this area (Project ▸ Project Settings... under “Backup”, though I definitely recommend visiting the overall options tab for backups too, as date stamps are going to be infinitely superior to a confusing serial number rotation list for this kind of purpose). With zipped copies of the project now being synced, a huge amount of the risks of syncing vanish.

You would definitely want to consider having two separate backup folders within the sync folder, one for each machine. They are going to be monitoring your folder for new copies of the project to merge into their copy of the project, and you will be monitoring their folder for updated .zips containing the merge of the combined edits since your last update.

4 Likes