Easy.

I first describe what I am using, then I would like to point out what I am be looking for, namely some wiki-like collaborative latex based software.

- What I doing.
Diff tools:

Let me first describe some diff tools I find handy: mgdiff,
which is only linewise, wdiff which is wordwise but whose
formating is not very attractive, then within (X)emacs,
ediff, which can compare wordwise, whose output is nicely
formated and most important has a nice merging toos (see
below). However the ultimative diff tools is, no doubt
*latexdiff*
(I just tried out ldiff and it does not come
close). Latexdiff also treats files under version control
which is very nice.

- revision tools. I use within Xemacs RCS with the vc
backend, my colleagues (still) don’t. So that works
roughly the following

I start my version say result.tex and use, within Xemacs
vc-visit-other-version
I select latest and then I obtain result-rev-1.1.tex
I send that version to my colleague who is making his
changes and send me back the file. I check that new file
in using RCS. Then I run
`latexdiff-vc-fast-file-current-inferior’
a small lisp hack which calls latediff-vc in an
appropriate manner.
This generates result-diff1.1.tex which I run pdflatex
over and send this pdf file back to my colleague.

I apply my changes check out,
run
vc-visit-other-version (1.3)
`latexdiff-vc-fast-file-current-inferior’
This generates result-diff1.2.tex which I run pdflatex and
then both files to my colleague.

Works pretty well.

- MERGING. It somehow can happen that two versions have to
be merged. Then meld or ediff with in Xemacs are good
tools. A merge however is cumbersome no doubt.

- what I would love to see is as I said I would like to point
out what I am be looking for, namely some wiki-like
collaborative latex based software. It seems that may be
lyx will offer something like this in the feature.

Uwe Brauer

it compares two similar tex files and creates one with changes in a graphical way similar to word or openoffice.
the revision is also possible.

for windows users latexdiff is a part of MikTex, for linux download from ftp://cam.ctan.org/tex-archive/support/latexdiff.tar.gz

The latexdiff script makes use of the Perl package Algorithm::Diff (available from http://www.cpan.org, current version 1.19)
so you need to have perl installed.

See http://scplugin.tigris.org/

@gray, I agree, TortoiseSVN is recommended by most of my Windows-based developer collaborators. I’m on Mac OS and for my development projects I use a combination of command line and Subclipse (a plugin for Eclipse), although I’d never recommend Eclipse for collaborative authoring (any of you using TeXlipse by any chance?). I wish there was some SVN interface built straight into TeX front-ends (as per my comment above) so as to make updating, diffing and merging as seamless as saving a document in a word processor.

I haven’t used it for co-authoring, but I do use it for backing up my work — all of the repositories are on the university server, and the local copies are on my laptop. If I were working with other people, I assume all they would have to do is install TortoiseSVN and checkout copies onto their own machines.

For comparing two LaTeX files looking at output from ‘diff’ is a pain in the ass, so I whipped together a small script that takes file1.tex, file2.tex and produces a diffFile.tex. The diffFile.tex uses a package called correct.sty and color.sty to create a pdf that has the same kind of markup that you get from track changes.

It works by serialsing both initial files into word lists, and doing a diff on the lists. There is some regex work going on to take care of some LaTeX syntax, but it’s not 100% robust.

I’ve had this stuff sitting on my hard drive for a few years, but wasn’t using it any more, so I’ve just popped it up on Google Code:

http://code.google.com/p/texdiffer/wiki/QuickStartGuide?updated=QuickStartGuide&ts=1217515515

If I get time over the weekend I’ll post the other version of the code, which might be more robust, but I can’t remember.

Let me know whether this is at all useful.

If you find the use of these systems difficult, you can consider using GUI tools that make this process much simpler, even for new users. Two tools I can strongly recommend are SmartCVS and SmartSVN.

Cheers!

@T, I didn’t know LyX supported revision tracking, I’ll definitely check it out (although I don’t see myself abandon my current TeX editing tools anytime soon).

@Hadley, mail+Git sounds like an interesting solution, in the end there are wiki engines or hosted wikifarms out there accepting revisions by mail or SMS so I don’t see why this should not be possible to have with an RCS back-end.

I guess any viable solution for non-programmers would need at the very least to:
1. make the commit process seamless (either via email or via plugins directly integrated in the front-end)
2. allow easy diffing/merging between TeX revisions, avoiding the annoying issues pointed out by Peter and others.

(@Peter, incidentally, I would not recommend CVS to someone willing to learn revision control from scratch).

Regarding diff optimized for LaTeX, there is a latexdiff package at CTAN as well as a Perl script (not actively maintained any more though) that may turn out to be useful.

Initially: One person (you) create the document, put in all the usepackages, and make all the sections in the .tex. Make sure the document renders, and check in the document and the .cls.

Others: check out that document.

Repeat:

1) cvs update
2) Edit “your” section.
3) cvs update, check for any messages about conflicts (and solve them).
4) cvs commit -m ‘Nice short description’

Always stop on point 4 when you leave for the day, even if your work is unfinished. Not having thousands of lines of uncommited content will make it a lot easier to resolve any conflicts, but will make it harder to back out changes. Since this is an article of 50 pages (tops) chances are you will finish it before you need to make any backouts. Make sure your commits never breaks the document rendering, since that breaks it for all others too.

If you stick to editing things in “your” designated section and never change names of sections you will not have any conflicts. If you need to edit someone elses section, sync with them through email/phone or simply tell them to insert your paragraph between these two other paragraphs.

The others have to learn two commands: cvs update and cvs commit, nothing else. For those who know the RCS you get all the goodies like cvs diff, commit history and so on.

I keeping looking for better solutions, but I’ve yet to find an interface where I’m the only one that needs to know about the rcs. http://gist.github.com/ looks promising but requires copying and pasting and a knowledge of how works work with git/github. Dropbox (http://www.getdropbox.com/) is another possibility - you can share files, and revisions are automatically tracked, but there’s no way to programmatically get at previous revisions. (I can send you an invite if you want to try it out)

I think my ideal solution would have an email front end and git back end. Email is how most academics deal with the problem now, and would provide a familiar interface. To use the system, you’d just cc a special email address and the site would do the rest - the git back end would make it easy to track changes and resolve conflicts, and advanced users could work directly from the command line.

Rob: a good diffing algorithm should be able to ignore those whitespace related changes - http://code.google.com/p/google-diff-match-patch/ does a particularly nice job.

One problem with RCS and my manual system is that the addition of a single word can lead to changes in every line of the paragraph due to auto-wrapping.

Most of the time I work with paper copies, when possible.

Skim (on Mac) provides a usefull notes/comments feature on PDFs.

But I didn’t find any long-term solution yet.