Revision control for LaTeX: in search of an answer
July 30th, 2008 by darioHere are a few posts that other readers recommend you check out:
As an ultimate LaTeX addicted, I hate to admit that there is nothing in the TeX universe comparable to the amazingly simple and intuitive revision tracking system that Microsoft implemented in Word. OpenOffice apparently has an equally powerful version control system built in its Writer.
Those of you who ever ventured into the territories of TeX-based collaborative writing certainly know how painful it can be to keep track of changes among several authors in TeX. TeX sources are raw text, so if you need proper diffing or revision tracking you will probably have to resort to some revision control system (such as Subversion or Git). Revision tracking via RCS, however, can be a nightmare to set up and learn to use fluently if you’re not already familiar with some basic notions of software revision control.
After an ugly lot of email exchanged with coauthors to let each other know who was doing what with a manuscript, I decided to search the Web for an answer.
Unfortunately, I couldn’t find anything particularly useful or enlightening. I came across this nice tutorial recently published in PracTeX describing a few steps to make the most of revision control in LaTeX via SVN and some dedicated packages:
U. Ziegenhagen, LaTeX document management with Subversion, The PracTEX Journal, 3 (2007).
(incidentally there’s also a SourceForge project for OpenOffice-SVN integration)
Using this solution still means convincing my collaborators to learn SVN, which I am not sure is a viable solution. I anticipate that the first who comes up with a good solution for revision tracking in LaTeX (e.g. a server-side tool similar to revision control systems but optimized for LaTeX and with good integration with a variety of TeX front-ends) will definitely become rich and famous.
Until this happens, I’d be curious to hear what strategies people use for TeX-based collaborative authoring.
About the author: Dario is a compulsive geek interested in human cognition and information technology, currently a postdoc fellow at the University of Surrey. He enjoys writing on social software, information foraging and raw seafood, occasionally. If you enjoyed this post, make sure you sign up for our mailing list or subscribe to our RSS feed!
July 30th, 2008 at 9:43 pm
LyX is able to track changes. It’s quite performing.
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.
July 30th, 2008 at 10:06 pm
I know it’s what you want to avoid, but I have to recommend using git (or svn if you must) for that kind of task. Sure, it will take some effort to learn, but it’s an investment that will pay of in many other areas, like programming.
July 30th, 2008 at 10:21 pm
When I saw your post title, I was hoping that you had an answer to this problem! I’ve searched and an RCS seems the only available solutions, but the costs in doing that are relatively high. My manual low-tech solution is to append an incrementing number to each version of the tex file (e.g., paper1.tex, paper2.tex, …). Then I use CSDiff or CompareIt! to identify the changes made.
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.
July 30th, 2008 at 11:00 pm
If you’re collaborating with just one other person, I find that email + rcs works ok. It’s not the perfect solution (you need to be pretty explicit about who is editing the document at each point in time), but it at least allows me to keep track of what I’ve changed, and what my co-author changed.
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.
July 31st, 2008 at 5:26 am
I use cvs out of old habit, but this works equally well for roughly any other VCS. Here is a workflow that keeps the amount of conflicts to a minimum for me:
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.
July 31st, 2008 at 6:30 am
Thanks all for sharing these tips, which confirm my initial impression about RCS as the best available solution.
@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.
July 31st, 2008 at 9:31 am
In my experience, using CVS or SVN are perhaps the best alternatives for this purpose. I use both extensively with my co-authors and the work flows seamlessly.
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!
July 31st, 2008 at 2:38 pm
Hi,
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.
August 1st, 2008 at 3:11 pm
TortoiseSVN is a pretty intuitive windows frontend for subversion. I don’t know how seemless you need, but pretty much everything can be done from a right-click on the appropriate folder or file.
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.
August 5th, 2008 at 8:47 am
@Ian, texdiffer looks fantastic, thanks for sharing this.
@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.
August 10th, 2008 at 5:24 pm
There’s a finder plugin for macos that covers much of the same ground as TortoiseSVN:
See http://scplugin.tigris.org/
August 12th, 2008 at 11:56 am
hi all, i tried latexdiff with a very satisfactory result.
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.
August 14th, 2008 at 9:55 pm
To extend on tracking changes using LaTeX… do some of you LaTeX users have to collaborate on papers with people who don’t even know that there alternatives to MSWord? I had to quit LaTeX because of that… It was too much a pain to go through the convert/adapt/…/ process for the colleagues to simply be able to open the document
Any suggestions?
August 15th, 2008 at 2:14 pm
i think that tracking changes is very helpful for publishing with non-tex people. these people just may fill tex files with text (created with probably known MS notepad:) and you can do tex-work yourself.
this attitude i tried several times. of course it depends on effort/effect ratio of a document. maybe in future the other people appreciate not only the quality of latex-made documents but also advantages in creating them (equations, bibtex … and index without repeating pain)
August 16th, 2008 at 6:39 pm
I’m using Bazaar for this purpose. It’s a distributed version control system very easy to use. What I love is that it doesn’t need a special server, it can upload your tree to any sftp. Its commands are very intuitive (it is used by the Ubuntu community) and it is multiplatform, as it is written in python.
September 24th, 2008 at 10:25 am
You may want to try the trackchanges package from sourceforge. This can be used to (as the name suggests) track changes.
September 24th, 2008 at 4:00 pm
Hello
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
October 17th, 2008 at 11:57 pm
I use a wiki for my research, which is not collaborative in my case, but could be. I then export to latex format via Word and Word Macros. So my changes are recorded in the wiki.
Easy.