How do I use Scrivener 3 with two authors

[nwconsulting]

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

[Kinsey]

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:

viewtopic.php?f=2&t=37878

viewtopic.php?f=4&t=39018&hilit=collaboration

[rdale]

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:

1. Set up your binder the way you want them to see it. It's best to avoid rearranging too much stuff in the binder during this process.
2. File->Save As to create a duplicate. I recommend putting your collaborator's name or initials in the copy's name.
3. Transport this other author's copy to them however makes the most sense. The next few steps make it easier to mail to them,or to share it with them... Ask for help if your sharing method will differ.
4. Quit Scrivener or at least close that project.
5. In the finder, create a .zip archive of the project for easier transportation. I believe the CMD-click option is "compress" or similar.
6. Mail the .zip file that results from compressing the project.
7. Once they acknowledge they have the copy, delete that copy from your computer to avoid confusion during the import process later.

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...

1. Run a backup on your work using either File->Back up->Back Up Now, or "Back Up To..."
2. Use File->Import->Scrivener Project on your co-author's work.
3. Verify that your work is untouched, and that their work has been imported.
4. Trash their updated copy.
5. Make sure they know to throw out their copy. Any further changes they make to that copy will probably be much harder to merge back to your original.

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.

[seefilms]

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.

[xiamenese]

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

[lunk]

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.

[rdale]

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.

Write out any set of actions one must take to accomplish something, and it will look "insane."

How to drive a car:
1. Walk up to the car
2. Pull up/squeeze the door handle until the door unlatches. If it does not unlatch, see #3, if it does, skip to 4
3. Unlock the door and go to 2.
4. Pull the door fully open.
5. Carefully climb into the driver's seat, careful not to bump your head on the door frame.
6. Put the key in the ignition
6a. If you have a location for your phone to charge and/or connect to your stereo, arrange that now.
7. Fasten your seatbelt.
8. Check your mirrors, adjust as needed
9. Make sure your seat is adjusted correctly; especially important if you share the car with another driver
10. Press down on the break pedal. If driving a manual transmission vehicle, also press down on the clutch pedal
11. ...

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!

[amekassa70]

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

We both have Scrivener 3 on Mac, how can I do what I need.

[JimRac]

We both have Scrivener 3 on Mac, how can I do what I need.

Follow Lunk's instructions:

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.

[jcarman]

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.

[polleke]

Collaborative writing comes in at least two modes:

1. Real-time working together, and seeing each others modifications at the moment that they are made;
2. Independently working together on one's own copy, and merging the results as soon as you are done writing (or any other moment you feel an update is required)

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 separation of concerns (SoC) 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

[devinganger]

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.

I see two main issues that would make Git integration with Scrivener more trouble than it's worth:

1) 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.

2) 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.

[kewms]

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

[polleke]

Indeed, Devinganger describes a clear problem which needs to be addressed:

I see two main issues that would make Git integration with Scrivener more trouble than it's worth

while Katherine presents the key to its solution exactly the way that I intended but failed to mention:

(...) but Scrivener 3 supports an Import and Merge mechanism designed specifically for scenario #2

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

[devinganger]

Or do I overlook something?

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.