Hi, I am new to Scrivener and the forum.
I have been working on a large document that has lots of folders and sections. I now need to pass the document to a co-author who is going to rewrite parts of what I have done whilst I need to continue to work on other parts of the document.
We both have Scrivener 3 on Mac, how can I do what I need.
Thanks
Nathan
There are several discussions regarding collaborating using Scrivener on the forum. Some of the advice might be slightly outdated now, however, as the refer to Scriv 2. Try these to start:
https://forum.literatureandlatte.com/t/collaborating-with-scrivener/37518/1
Once, and once only, you can do a “save as” of a project, modify (or have someone else modify) that copy, and then merge that copy back with the original. After that point, you’d have to do a File->Save As again, pass it to your collaborator, and repeat the process. If they send you their updated version, you merge it with your copy, and then they send you another change made with the same copy they already passed back, you probably won’t be able to merge the latest changes.
So,the steps are as follows:
Refrain from editing the documents that your co-author will be touching, and be sure they don’t do anything with the documents you will be working on during this period of sharing.
To merge back, once you receive their updated copy…
Repeat the whole process again to continue collaborating.
See section 5.1.7 “Merging Projects” for a more in-depth, and likely more accurate, explanation of how to do this.
Or, in other words, there really is no sane way to do this.
Because, if every time I needed to send a document to my writing partner I had to go through that kind of process…
I’d be insane.
Amazing product. Unless there are two authors.
The only other way—as I have been doing for years—is to co-ordinate working so you don’t have the project open at the same time. But that is easier for us as my collaborator is 7–8 hours away in China. And that it seems is not acceptable.
To make simultaneous editing possible would be a huge task for a very small company, and while I’m sure KB would say "never say ‘never’ ", I really wouldn’t hold your breath!
Mark
If you have Dropbox and have your Scriv projects in a designated folder, put the mutual project in a subfolder and give your co-writer access to that. Then make sure you open the project, write, close it, and then tell your co-writer it is closed.
If either one of you try to open the project while it is already being opened by the other, you’ll get a message saying that and you can then simple refrain from opening it.
Write out any set of actions one must take to accomplish something, and it will look “insane.”
How to drive a car:
Insane, isn’t it! Yet people do it every day without thinking about all those steps (and more, for some vehicles).
When writing out technical instructions, one must break down the steps, and take alternatives into account, or risk the recipient’s confusion or frustration. I could have just said, “Do a Save As, don’t edit the project (or at least don’t edit anything the other author will touch), then use the import function when they return the copy. Trash the save-as copies, and create another as needed for your collaborator.” Does that sound “insane”? If so, the compile process will break your mind and send your soul into the abyss!
We both have Scrivener 3 on Mac, how can I do what I need.
Follow Lunk’s instructions:
You could use the Scrivener file as a repository using a versioning system, updating it on a schedule to avoid conflicts and otherwise writing in something else or another Scriv. project, committing finished parts to the repository.
Or not.
Collaborative writing comes in at least two modes:
Regarding ease of integration into Scrivener, from the perspective of a software architect and engineer, i.c., myself, I consider the second mode of working together far more easy to integrate in Scrivener, and agree that the first mode of collaboration is quite a complicated functionality that makes the term “ambitious” a rather understatement.
Regarding what to wish for, for me, a scientist who write together with or as co-author, I’m not that much interested in the real-time mode of collaboration. I think it even distracts from your own line of thinking and we therefore should introduce what is called a [i]separation of concerns /i where one concern is the ability to focus on your own work, and another concern is to have multiple individuals to contribute to the result, such as reviews or modifications. A third concern would be to assure that merging texts do not mess-up the texts as we need to combine the first two concerns together.
The second concern calls for a master document that represents the current stable stage of what has been written by the mutual brains so far; the first concern demands the existence of several copies and versions of the master document, one for each of the individuals to work on separately and independently; the third concern calls for a means to assure, under any circumstance, that merging (different versions together into an updated version of the master document) does not introduce text conflicts, and when conflicts emerge (they do), have a proper tool to support a user in the resolution of the conflict in a seamless way and produce the new and stable version of the master document.
These demands for this second mode of independently working together is not new. In fact, in software engineering this is a rather established way of collaborative software development, denoted as version control, source code control, and several other terms. And although there is quite a difference in what is being produced (a highly structured piece of source code, versus a “structureless” piece of text which can be formulated in ever so many variations), the foundations of the process are identical. So it is no surprise that several collaborative writing tools exist that are based on Git (e.g., draftin.com, overleaf), and I don;t see any reason why Scrivener could not introduce such relatively simple collaborative process with a dedicated Git server in the background. Indeed, such an approach does not support the real-time mode of collaborative work, but introducing the feature to independently working together is definitely a highly welcomed functionality for Scrivener’s user community.
Although the members of the community are of course the judge of that, so please give your opinion!
Best
Paul
I see two main issues that would make Git integration with Scrivener more trouble than it’s worth:
Git’s conflict detection and resolution is predicated on having plain-text documents for it to analyze. Scrivener’s project format is based of RTF, for multiple reasons that have been clearly articulated elsewhere, As a result, Git could not detect whether there were changes within a document, only whether the document had been changed, and that would add more overhead to users who were merging changes.
Git assumes that users have visibility into – and want/need to know about – every file contained within a project. A Scrivener project has lots of files that users do not normally need to be aware of and should not be manually messed with. They can’t be ignored by Git – they need to be synced – but their contents are linked to the contents of the various RTF files, so there is a very real risk of the contents getting out of sync in a situation where multiple users work on the same document(s) at the same time and merge back to the same branch. Git would either need to be enhanced to understand how Scrivener works, or Scrivener would have to have exhaustive knowledge of how Git handled merges and programmatically handle some of the inevitable conflicts and hide them from the user. Both approaches would require far more work than would be practical.
Both systems are good, but they are built on incompatible assumptions about how a project is handled.
I don’t know if it’s fully implemented in the Windows beta yet, but Scrivener 3 supports an Import and Merge mechanism designed specifically for scenario #2.
As Devinganger notes, Git is not really a good alternative because RTF files are less human readable to a writer than code is to a programmer.
Katherine
Indeed, Devinganger describes a clear problem which needs to be addressed:
while Katherine presents the key to its solution exactly the way that I intended but failed to mention:
Having already the capability to base its synchronization on text files only, as opposed to the project’s RTF-base, Scrivener can avoid the RTF issues explained by Devinganger’s 1st issue. And since Scrivener in this way is already capable of synchronizing only the contents of the project without taking the files for the application’s internal operations and state into account, the sync-issues as explained in the 2nd issue can be circumvented as well.
This approach would result in a loosely-coupled synchronization mechanism between two instances of Scrivener, or one Scrivener instance and any another application (that supports text file based writing) through git. This requires the Scrivener application to plug some specific script on when and how to sync/merge and how to combine that with git’s pull / update / branch / mergetool and push operations.
Or do I overlook something?
Best
Paul
Scrivener’s base use of the RTF format for the actual document content is what allows many of the key features and functionality of the program to exist. It’s one of the core design principles of the program, not a flaw or problem to be solved.
The import and merge functionality is not based on exporting text files; it’s designed to work with two separate Scrivener projects (RTF and supporting files) and allow you to selectively merge their contents together.
If you want pure text files so you can use your editor with Git, look for some other editor to use. Don’t demand that KB re-design and re-write Scrivener from the ground up.
This statement is not accurate.
Scrivener does not create or manipulate plain text files unless you explicitly tell it to as part of an export operation. The internal project files containing your work are always RTF.
Moreover, the Import and Merge feature emphatically does consider the metadata that defines, for example, the structure of the Binder. That information is part of the “contents” of the project. If you attempt to manipulate the RTF files independent of those structural files, you are almost guaranteed to render the project non-functional.
Katherine
I while I do still hava a license, I think I would no longer use Scrivener until it would use native markdown format. Using markdown would sort the GIT issue and also play well with other tools/platforms.
I may be biased because I need it only for technical writing in a collaborative manner, where multiple people could change it.
PS. I know enough about RTF format to want to run from it at any cost 
We’ll miss you, but this is unlikely to happen.
Katherine
Is there a modding community? Is this a possibility?
No, and no.