Collaborative Screenwriting?
April 3, 2010 3:14 PM Subscribe
Version control for collaborative (screen)writing - what's the solution?
I'm starting to write a screenplay with a friend of mine. I'm looking for a solution to avoid the inevitable version control/revision issues that come with emailing copies of the file to eachother, uploading hundreds of revisions to google docs (screenplay_1.txt, screenplay_2_old.txt, screenplay_newer.txt), and so on. Things I've looked at:
source code CVS's (SVN, Mercurial): Firstly, they seem to introduce a lot of overhead in workflow for the fact that we're only two people. If there's an easy way to do it right, I'd be all ears, but I'm a little shaky on using them and my partner has no experience using them. He's the type of person who would just keep using the old method of renaming files instead of learning a new method that wasn't super user friendly.
To test Mercurial, I tried to simulate a situation that would arise often with multiple people working on the same file:
I wrote a simple scene, then checked it in. I cloned the repository to simulate my friend working on something in parallel. In the first repository, I corrected some spelling and added a line of dialogue to the first scene. In the second repository (my "friend's"), I added another scene. Then I tried to merge changes, and every diff tool that came with TortoiseHg utterly failed to allow me to merge them easily. None of them allowed me to move down the 2nd scene to accomodate the new dialogue in the 1st scene, short of manually editing it - doesn't this situation come up a lot in source code? It didn't seem 'smart' at all, like the buzz I've been hearing about Git and Mercurial, it seemed dumb as dirt. What happens during programming, when someone adds a line of code to a first method, and someone else adds a second method? It's the exact same situation, and doesn't seem easily resolvable.
Celtx Studios: It's a service offered by the makers of the open source screenwriting software Celtx, that's supposed to aid collaboration, project snycing, and has revision control. It's super limited, costs 5 dollars a month and uses a simplistic "project locking" model to prevent edits to the entire project when one user is using it - that has to be manually flipped back and forth by a master account. It's the best solution I've found so far (I already paid for a month), but it's annoying and leaves much to be desired.
I suppose screenwriting or novel-writing is different than code-writing in that we're only two people, only working on one file (and some secondary files with notes), so a "locking" model might actually be better here - but Celtx Studios' is still much more limited than I'm looking for.
Final Draft: It has a "Collabowriter" feature, but it's only for pair-writing over the internet, with no revision control or management.
Scripped, Adobe Story: Web-based, laggy, would be nice to use any editor we want and just use some kind of revision control system for syncing.
Am I asking too much? It seems like this should be a "solved problem" - maybe not for screenwriting alone, but for novel writing, or report writing - any collaborative writing? To summarize: I'm looking for a way to sync copies of a single text file (or multiple text files) between two people, while keeping track of every change made. A locking model is okay, as long as it's easy to use. Features like real-time collaboration would be nice, but not necessary.
Thanks!
I'm starting to write a screenplay with a friend of mine. I'm looking for a solution to avoid the inevitable version control/revision issues that come with emailing copies of the file to eachother, uploading hundreds of revisions to google docs (screenplay_1.txt, screenplay_2_old.txt, screenplay_newer.txt), and so on. Things I've looked at:
source code CVS's (SVN, Mercurial): Firstly, they seem to introduce a lot of overhead in workflow for the fact that we're only two people. If there's an easy way to do it right, I'd be all ears, but I'm a little shaky on using them and my partner has no experience using them. He's the type of person who would just keep using the old method of renaming files instead of learning a new method that wasn't super user friendly.
To test Mercurial, I tried to simulate a situation that would arise often with multiple people working on the same file:
I wrote a simple scene, then checked it in. I cloned the repository to simulate my friend working on something in parallel. In the first repository, I corrected some spelling and added a line of dialogue to the first scene. In the second repository (my "friend's"), I added another scene. Then I tried to merge changes, and every diff tool that came with TortoiseHg utterly failed to allow me to merge them easily. None of them allowed me to move down the 2nd scene to accomodate the new dialogue in the 1st scene, short of manually editing it - doesn't this situation come up a lot in source code? It didn't seem 'smart' at all, like the buzz I've been hearing about Git and Mercurial, it seemed dumb as dirt. What happens during programming, when someone adds a line of code to a first method, and someone else adds a second method? It's the exact same situation, and doesn't seem easily resolvable.
Celtx Studios: It's a service offered by the makers of the open source screenwriting software Celtx, that's supposed to aid collaboration, project snycing, and has revision control. It's super limited, costs 5 dollars a month and uses a simplistic "project locking" model to prevent edits to the entire project when one user is using it - that has to be manually flipped back and forth by a master account. It's the best solution I've found so far (I already paid for a month), but it's annoying and leaves much to be desired.
I suppose screenwriting or novel-writing is different than code-writing in that we're only two people, only working on one file (and some secondary files with notes), so a "locking" model might actually be better here - but Celtx Studios' is still much more limited than I'm looking for.
Final Draft: It has a "Collabowriter" feature, but it's only for pair-writing over the internet, with no revision control or management.
Scripped, Adobe Story: Web-based, laggy, would be nice to use any editor we want and just use some kind of revision control system for syncing.
Am I asking too much? It seems like this should be a "solved problem" - maybe not for screenwriting alone, but for novel writing, or report writing - any collaborative writing? To summarize: I'm looking for a way to sync copies of a single text file (or multiple text files) between two people, while keeping track of every change made. A locking model is okay, as long as it's easy to use. Features like real-time collaboration would be nice, but not necessary.
Thanks!
You could also try Google Docs. The downside is you need to be online while you use it.
posted by lilac girl at 4:08 PM on April 3, 2010
posted by lilac girl at 4:08 PM on April 3, 2010
Response by poster: Sorry, I should have clarified that something like google docs or google wave are not what I'm looking for - they require me to use their editor to get revision control (and google docs doesn't even seem to have revision control), I can't use Final Draft or Celtx to write the thing offline. Screenwriting in a pure text editor like docs or wave is annoying and unfeasible, you have to tab out each line, etc.
posted by nervestaple at 4:13 PM on April 3, 2010
posted by nervestaple at 4:13 PM on April 3, 2010
Off the top of my head: Try Etherpad (doubt it has the version control system) and try TextFlow which allows you to view different versions of a document simultaneously highlighting the differences, may be an alternative to version control.
posted by iNfo.Pump at 4:55 PM on April 3, 2010
posted by iNfo.Pump at 4:55 PM on April 3, 2010
Off the top of my head: Try Etherpad (doubt it has the version control system)
Etherpad, sadly, is shutting down in a month.
posted by special-k at 5:16 PM on April 3, 2010
Etherpad, sadly, is shutting down in a month.
posted by special-k at 5:16 PM on April 3, 2010
You might find that the source code system git is a better choice than either of the revision control systems you mention.
While it isn't really that much more user friendly than the other systems, it does have the distinct and overwhelming advantage that nobody has to administer a server. Your working directory becomes a full-fledged repository.
It has a GUI, though, that appears to come bundled with the installer packages. That might make it more user friendly from your friend's perspective.
One thing I wonder about, though, is whether any version control is going to properly handle a screenplay in Final Draft or similar format. If I recall correctly from my days in film school, the files used by the major commercial screenwriting programs have all sorts of binary formatting sludge in them. So a version-control system is going to have trouble giving you meaningful diffs and merges, since they aren't line-oriented plain text.
posted by Netzapper at 5:18 PM on April 3, 2010
While it isn't really that much more user friendly than the other systems, it does have the distinct and overwhelming advantage that nobody has to administer a server. Your working directory becomes a full-fledged repository.
It has a GUI, though, that appears to come bundled with the installer packages. That might make it more user friendly from your friend's perspective.
One thing I wonder about, though, is whether any version control is going to properly handle a screenplay in Final Draft or similar format. If I recall correctly from my days in film school, the files used by the major commercial screenwriting programs have all sorts of binary formatting sludge in them. So a version-control system is going to have trouble giving you meaningful diffs and merges, since they aren't line-oriented plain text.
posted by Netzapper at 5:18 PM on April 3, 2010
Response by poster: Netzapper: Yeah, I figured I could sidestep the binary issue... Final Draft and Celtx both have a "save to plain text with formatting option". It seems to work well, you can save in one and open in another and they read just fine. Also, I believe the latest version of Final Draft uses XML-based plain text like DOCX in Office 2007, so it would work fine also.
I was under the impression that Git and Mercurial were more or less equivalent. I chose Mercurial (TortoiseHg) because it plays nicely with Windows. Anyway, if git handles merges differently somehow, and could solve the problem I mentioned, I'd happily try it out.
posted by nervestaple at 5:36 PM on April 3, 2010
I was under the impression that Git and Mercurial were more or less equivalent. I chose Mercurial (TortoiseHg) because it plays nicely with Windows. Anyway, if git handles merges differently somehow, and could solve the problem I mentioned, I'd happily try it out.
posted by nervestaple at 5:36 PM on April 3, 2010
I'm sorry. I didn't fully read your complaint about the merges.
The situation you described does come up all the time. Unfortunately, you have to think about this from the diff program's perspective: if the two edits overlap, it cannot tell the difference between adding a single line of text to the end of a file, and adding a page of text.
One reason not much effort is put into solving this problem for source code is that in code, one of the two answers is usually correct--that is, you almost never want both revisions. And, if you do want both revisions, somebody needs to put some brain time into figuring out how they go together--automatically including all changes tends to lead to much pain.
Another reason is that we tend to have separate files for separate functional units, and that people's tasks are usually assigned along the lines of functional units. We have a separate file for every module, and we tend to only have one person working on a module at a time. If you wrote each scene in a separate file, you'd never have encountered this problem.
But the main reason we don't worry about it much in code is that we have many more "anchors" in code than you do in a script. For instance, in your code example of editing Method A while somebody else adds a Method B, you have to remember that there's a curly bracket1 at the end of Method A. So the diff tool can pick up that bracket as unedited in both copies, and recognizes that the two edits are actually to different regions of the file.
One thing you might try is to repeat your test with Mercurial, but add some symbol to the end of every scene. For instance, you might go with the classic "***". If every scene ends with "***" on a line by itself, and the end-scene token is checked in when the scene is checked in, and people aren't editing the same scene at the same time, you might find than many of your manual merging problems go away. I know it isn't proper formatting, but you can just blow them away when it comes time to print them up on three-hole paper with the powder-blue cardstock cover.
1Or a newline and unindented blank line, or a pipe, or an 'end'. Something that denotes the end of a function.
posted by Netzapper at 6:48 PM on April 3, 2010
The situation you described does come up all the time. Unfortunately, you have to think about this from the diff program's perspective: if the two edits overlap, it cannot tell the difference between adding a single line of text to the end of a file, and adding a page of text.
One reason not much effort is put into solving this problem for source code is that in code, one of the two answers is usually correct--that is, you almost never want both revisions. And, if you do want both revisions, somebody needs to put some brain time into figuring out how they go together--automatically including all changes tends to lead to much pain.
Another reason is that we tend to have separate files for separate functional units, and that people's tasks are usually assigned along the lines of functional units. We have a separate file for every module, and we tend to only have one person working on a module at a time. If you wrote each scene in a separate file, you'd never have encountered this problem.
But the main reason we don't worry about it much in code is that we have many more "anchors" in code than you do in a script. For instance, in your code example of editing Method A while somebody else adds a Method B, you have to remember that there's a curly bracket1 at the end of Method A. So the diff tool can pick up that bracket as unedited in both copies, and recognizes that the two edits are actually to different regions of the file.
One thing you might try is to repeat your test with Mercurial, but add some symbol to the end of every scene. For instance, you might go with the classic "***". If every scene ends with "***" on a line by itself, and the end-scene token is checked in when the scene is checked in, and people aren't editing the same scene at the same time, you might find than many of your manual merging problems go away. I know it isn't proper formatting, but you can just blow them away when it comes time to print them up on three-hole paper with the powder-blue cardstock cover.
1Or a newline and unindented blank line, or a pipe, or an 'end'. Something that denotes the end of a function.
posted by Netzapper at 6:48 PM on April 3, 2010
What Netzapper said.
I forget where I heard it, but someone gave me the impression that one of those fancy screenplay writing programs uses TeX/LaTeX "under the hood" so-to-speak. If true, you might be able to get better results with a source code RCS/CVS by using that system's "native" files which could be in some dialect of TeX. Even if they've "updated" to some dialect of XML, it would still be more "regular" than a plain text file. Wouldn't hurt to take a closer look at the native files of, say, Final Draft and see what they are.
(And if not, I used ScriptTeX for a couple of small projects. It was simple and seemed to work alright for what I needed at the time.)
posted by wobh at 8:11 PM on April 3, 2010
I forget where I heard it, but someone gave me the impression that one of those fancy screenplay writing programs uses TeX/LaTeX "under the hood" so-to-speak. If true, you might be able to get better results with a source code RCS/CVS by using that system's "native" files which could be in some dialect of TeX. Even if they've "updated" to some dialect of XML, it would still be more "regular" than a plain text file. Wouldn't hurt to take a closer look at the native files of, say, Final Draft and see what they are.
(And if not, I used ScriptTeX for a couple of small projects. It was simple and seemed to work alright for what I needed at the time.)
posted by wobh at 8:11 PM on April 3, 2010
Response by poster: Netz: Thanks for the explanation, and the suggestion for tokens! I figured it was merely my misunderstanding of how merging was actually done, but I couldn't seem to find anyone explaining the details while googling. I don't know why I expected the diff tool to understand the concept of "new scene."
posted by nervestaple at 9:07 PM on April 3, 2010
posted by nervestaple at 9:07 PM on April 3, 2010
One reason not much effort is put into solving this problem for source code is that in code, one of the two answers is usually correct--that is, you almost never want both revisions.
Really?? There's a reason it's called a merge. In my experience 99% of the time the point is to merge two sets of changes into a version that has both.
I think you should try again with source control, and potentially give git a try. Your merges should absolutely be easy. Was the "added line of dialog" at the very end of the scene?
In that case then of course there's no way for the merger to know how to order the two different edits that both look like "stuff added to the end of the file". However, the solution isn't to do a full edit. The merge program should have the option to manually adjust the alignment. I don't know what it'll be called in your tools but in Beyond Compare if I pulled up those changes and I saw the two adds on top of each other I'd manually align the first line of the second scene to after the new line of dialog. Literally seconds of time and I'd still clearly be able to see in the tool how simple the merge is.
(It occurs to me that Netzapper's comment about not wanting both changes may have to do with 2-way versus 3-way merges. Hopefully you can just get your writing done for a while before you need to become a VC expert.)
posted by Wood at 9:55 AM on April 4, 2010
Really?? There's a reason it's called a merge. In my experience 99% of the time the point is to merge two sets of changes into a version that has both.
I think you should try again with source control, and potentially give git a try. Your merges should absolutely be easy. Was the "added line of dialog" at the very end of the scene?
In that case then of course there's no way for the merger to know how to order the two different edits that both look like "stuff added to the end of the file". However, the solution isn't to do a full edit. The merge program should have the option to manually adjust the alignment. I don't know what it'll be called in your tools but in Beyond Compare if I pulled up those changes and I saw the two adds on top of each other I'd manually align the first line of the second scene to after the new line of dialog. Literally seconds of time and I'd still clearly be able to see in the tool how simple the merge is.
(It occurs to me that Netzapper's comment about not wanting both changes may have to do with 2-way versus 3-way merges. Hopefully you can just get your writing done for a while before you need to become a VC expert.)
posted by Wood at 9:55 AM on April 4, 2010
In my experience, the problem the OP describes happens with all version control systems. Anytime a coworker and I have done a large amount of work in the same file, conflicts have arisen, and merging has become a tedious and manual process. I do not think using git will solve this, as I think it's simply a limitation of merging algorithms.
posted by !Jim at 12:06 PM on April 4, 2010
Another reason is that we tend to have separate files for separate functional units.This. Merge conflicts are rare because most of the time, each programmer is working in a separate set of files. An option I would consider, therefore, would be to write your document using LaTeX. Then, each of you could have a chapter, or set of pages, organized in separate files. Then, you can
\include these separate parts into one master document which represents the script itself. As long as no two people are working on the same chapter at one time, there will never be an issue, and since the files are much smaller this way, merging manually will be much easier when that arises. Also, since you're merging simple text files, the tools are very much in place to do so.
Also, I believe the latest version of Final Draft uses XML-based plain text like DOCX in Office 2007, so it would work fine also.The docx format uses a bunch of xml files inside a zip container, so you'd have to use a specialized tool to merge them (you can verify this by opening one of them with your favorite zip program.)
posted by !Jim at 12:06 PM on April 4, 2010
This recent mefi post may finally solve your problem?
posted by lilac girl at 4:36 AM on May 10, 2010
posted by lilac girl at 4:36 AM on May 10, 2010
This thread is closed to new comments.
posted by pants tent at 3:44 PM on April 3, 2010