Read a lot of posts on the board about this, still not clear at all…
What is the best workflow for 2 Scrivener users (West & East Coast) who need to work on the same project ?
Ideally, I would like not to have to email the project every time… dropbox is fine but it doesn’t let us use the same dropbox external folder sync for two users.
Thanks!
Frederic
Hi,
You certainly should never use external folder sync for this, as you have found out.
Instead, you should put the project itself in Dropbox and work from that. Be sure to set up automatic backups to save somewhere outside of Dropbox, too, so that you always have a backup handy in case anything goes wrong.
You will not be able to work on the same project at the same time, but if you go to open the project while your colleague is working on it, Scrivener will show a warning telling you that somebody else seems to be using it - just be sure to heed that warning.
Hope that helps.
All the best,
Keith
Oh that makes sense. Thank you.
Is there a way to keep two different project files and sync them periodically?
Thanks,
Frederic
I think you’re going to be stuck manually “syncing” them. My suggestion would be to have one master project, with documents marked (using label colors?) for each author so that no one gets confused on what to work on. Then create “Save as” copies of the project, named for each author. Periodically, you’d open the master project, drag in your completed documents/text to “sync up”. At some point, to see the whole thing together, you’d archive your author copy and do another round of “Save As” from the master project, so that you have both authors’ work in your working copy.
This will require constant communication inside the project (maybe using the Status meta data) and outside using email, text messages, phone conversations, smoke signals, hand-written letters, or however you best communicate. But then again, I don’t know of many kinds of software designed for writers (as opposed to programmers) to edit documents simultaneously, but there are plenty of books co-written by authors who don’t live under the same roof. They must have had some system of passing the text back-and-forth, waiting for the other writer to be done. This will probably be the way of things for many years to come, as simultaneous document writing is fraught with peril.
Nicci French write alternate chapters (I think I remember reading) and edit each other’s work alternately; they (I presume) live in the same house, so the process must be relatively straightforward.
I’ve written TV scripts with others. For that kind of short-deadline project, either you sit alongside your collaborator(s) and the work is genuinely indissoluble although (inevitably) quite slow, or you write alternate drafts against an agreed outline. The latter is clearly possible at a distance although it can put additional wanted or unwanted responsibility on the first and last to touch the manuscript.
Why not build a check in and out system that locks documents when someone is editing it, into the software? Similar to what is done with code repositories for programmers or even databases like
FileMaker.
There was one (at least) extensive thread on this topic about, maybe, 18 months ago. If I remember correctly, Keith said he’d looked at it, but found it potentially very complicated to implement, made more so by the package nature of Scrivener projects - possibly an enhancement for the future, though. If you’re interested, it would be worth doing a forum search on “versioning” (not to be confused with Apple’s more recent “Versions” feature).
Of course, as Keith says above, the software already issues an alert if it suspects that a project is currently open.
Scrivener is coded by one person (me) and a full versioning system with check-in/check-out capabilities working off the network would be insanely difficult from a technical perspective. It’s not like working on lots of separate files like when you use something like subversion, because you have the binder file and suchlike that determines what the binder looks like and what is in it. There’s no way you could check that out and still have the other person open the project. Better collaboration features are on the list for the future (most likely for around version 4.0, if we have more resources and manpower by then), but are beyond our current resources and also a little out of scope of the original design.
All the best,
Keith
Wow Keith, great job!
It really doesn’t have to be that complicated I think. Have a ‘Collaborate’ feature switch and a master ‘rights’ file where each file either has an available or locked status. The status changes based on a user having the file opened in the app. A little lock would show up next to the filename in the app.
But then again, I’m not coding it! ;
Thanks,
F
The problem (well, one of them) is that it’s not just single files you’re dealing with that can be locked or not–both users need to access the files for the binder and such, in addition to the individual text documents, so there’d be no way to lock the binder files and allow both users access. From the perspective of the individual text documents it might be more feasible to lock some in a way that the other user just couldn’t load them, but there’s a whole framework around that which you can’t avoid touching.
I will throw in here though that I’ve used the Dropbox method to work collaboratively with other users and haven’t had a problem. If you’re both needing to work during the same hours it can be messier, I understand, but if you can work out a schedule whereby you get the project for a certain period and then close up and the other person can access it, you can make this work pretty nicely. And with labels, status, keywords, or collections (or an assortment of those) you can easily identify which documents you’ve been working in and so forth so when the other person fires up the project they can get a quick overview of what you’ve been doing if necessary.
What happens if Author A is applying changes to several different files, while Author B is revising the outline?
Katherine
As a writer who collaborates, I say that a primary rule is never work on a project file “at the same time” and you won’t have troubles. Use file dates to distinguish versions, and use two different colors of type to distinguish writers. Red/black or blue/black are very easy to spot. You may write comments, annotations, and project notes to each other when trading praise, complaints, or good-natured jibes.
Even if you are on a tight deadline, it’s better for writers A and B to work alternate shifts. If you cannot, then label the parts accordingly: Part 14A and Part 14B are the same part, revised by writers A and B, and you use split-screen to compare and produce Part 14AB.