Dan, there are so many issues here, actually. I have background both in the general problem and in some specific things I was asked to do on a consultancy once for the BBC.
There are two fundamentals:
-
one is the need for what is called ‘atomicity’ in replications. This means you deliver nothing but a fully integrated and consistent result: the total state of a multi-component Scrivener project at the point you saved it. This is not something Dropbox or the like can possibly provide, the way they are designed, unless the Scrivener project is archived into one single file for Dropbox to deal with.
-
the other is the need for intelligent merging. Only a person, and somewhat an informed person at that, can successfully compare and merge two versions of a Scrivener project. It takes knowledge, after you have the RTF and structure editors that Scrivener provides. And you only get the chance to do it if the first condition is fulfilled.
Without these, you will at any mysterious point get text that can’t be found, text that appears to be lost, even though at other times the Dropbox seems to work.
The simplest case for it is when one project-internal RTF file, which holds a scrivening, gets modified at both ends after the naive project directory is put into Dropbox (or closed from Scrivener there). Then Dropbox will create a re-named version of that RTF file, which you will never see in Scrivener. You could only manually find such files, and then, guess what, manually edit them in – which you can’t do from Scrivener itself.
There are all kinds of variations on the problem, and in proposing a solution, I found in reflection this morning that I’m still depending on Dropbox getting certain potentially tricky things right. Probably they do – as it’s a well-recommended program for many persons.
If you need another example from the field, that would be what happened when Dropbox-like programs first appeared 15 years ago, and the first thing that smarty people thought to do with them was run their Quickbooks accounting through files shared this way. Instant unreliability, for similar reasons, that a database also requires the ‘atomic = all at once or refuse changes’ approach. To actually have a database do this over distance is extraordinarily demanding, as someone’s husband above has mentioned, and costs it from Oracle or others.
Why do people think Dropbox just ought to work? Well, naive Dropbox and Scrivener can work, indeed – so long as their users are absolutely not naive.
If one or more persons clearly understand and absolutely accurately follow the sorts of absolute limitations with close, consistent communications Keith has outlined, then you can avoid the areas where trouble can come.
One mistake in that regime, and then trouble is perched on your shoulder. As in, two persons writing in the same area of a document – or one person doing so from two locations without remembering to have closed Scrivener down fully before they left the one where they’re not. Or additional scrivenings added, same fault circumstances.
In the end, choices are often a matter of trading off apparent convenience with risk. I’ve hoped the discussion here would end up with a way to take the risk out, but still leave Dropbox useful. That we’ve done that and raised Google Docs as the way to do true 'writing together, seems worth the candle.
Best to each,
Clive
