News for hackers. Stuff that matters.
Re:Two dozen mathematicians wrote a 600 page book in 6 month... by mjn on Thursday June 20, 2013 @04:56PM (#5914909)
I haven't found git to work much differently in practice, at least with papers (I haven't written a book in it). You will end up with way too many conflicts unless you basically "lock" sections through either a software mechanism or agreement, because edits often touch or reorder many paragraphs. A copyediting/wording pass will typically touch every paragraph, for example, and these are more frequent in writing than refactoring or variable-renaming passes are in coding.

You can somewhat improve the situation if you adopt a somewhat weird source-formatting policy, where you write each sentence on one separate long-ish line, rather than flowing by paragraph. Then you will be able to automatically merge as long as nobody has made an edit or move that touches the same sentence, giving you better merge granularity. But even then conflicts happen pretty often, and few people like this style of formatting (maybe it'd work better with tool support).

For a book this might work better, though, because I assume you'd be making less frequent edits, and people would less often be working at the same time.

Re:Two dozen mathematicians wrote a 600 page book in 6 month... by jessriedel on Thursday June 20, 2013 @05:15PM (#5915032)
Note that in principle it's probably better to change your diff software to recognize sentences than to change how you write your latex.
Re:Two dozen mathematicians wrote a 600 page book in 6 month... by nickzoic on Saturday June 22, 2013 @04:17AM (#5922936)
Sure, but in practice, starting each sentence on a new line isn't difficult and works great with standard 'diff'. I actually quite like it for proofreading, since fragments and run-on sentences jump out at you.
Re:Two dozen mathematicians wrote a 600 page book in 6 month... by dbaupp on Thursday June 20, 2013 @09:33PM (#5915988)
> You will end up with way too many conflicts unless you basically "lock" sections through either a software mechanism or agreement, because edits often touch or reorder many paragraphs. A copyediting/wording pass will typically touch every paragraph, for example, and these are more frequent in writing than refactoring or variable-renaming passes are in coding.

As stated above, Dropbox doesn't even try to merge files, but Git does, which is definitely an advantage (at the very least, it tells you where the conflicts are, which is far more reliable than trying to work out the conflicts by hand, or with a separate diffing tool).