Linus mentions that git doesn’t track files but tracks content. This could be especially useful for work in latex, where one often moves passages of text from one file to another. I suppose a content-based rather than file-based addressing system would make it much easier to merge a selected set of meaningful blocks of text and track that change.

On the other hand, I am bit disturbed by git’s poor windows support and by Linus’s focus on speed and large codebases. All of this suggests the system has been highly optimized around problems very specific to the linux kernel. Mark Shuttleworth and the Bazaar website make a good pitch for the value of a lossless repository, especially for relatively small projects.

My impression is that all these systems support integrating with svn. The quality of the GUI’s for history-tracking and merging will probably decide how much value these features really add for writing.

Please elaborate. What are those opportunities? This suggestion alone is far more intriguing than things like offline commits, which are touted everywhere and more of a convenience than a new way of working.

There are several. Chief among them is the ability to merge some but not all differences. I would like to be able to pick the changes to merge. I discussed this here, there is a little more discussion of this in section 2.4 of “Subversion and TextMate: Making colaboration easier for LaTeX users”. This section also describes a fix, in subversion, with svnmerge.py. I have played with svnmerge.py, but utlimately I found it awkward to use in practice and an inelegant solution.

The problem, of course, is that subversion is broken by design. See Linus Torvalds google talk I embedded in this post.

It’s too hard to get an overview of a document structure, to zoom in/out

This is one of the benefits of using an editor that supports code folding. ;)

to describe and save chunks of text for insertion later

OK, but there are a number of ad hoc ways of dealing with this.

to save associated assets (figures, etc.) in an orderly way.

As you mention, RefTeX does this. TextMate has similar in built facilities for dealing with LaTeX documents.

to see visually how a document changes over time

Totally agree with you about this. This is part of the reason that I have claimed before that none of the GUI implementations of subversion are compelling.

There’s a long way to go.

Agreed, but I still believe that text based solutions will you get you further than any alternatives that I know of, and there is room to extend the existing text based solutions.

Prose production presents opportunities for merging that subverion cannot handle (at least at present).

Please elaborate. What are those opportunities? This suggestion alone is far more intriguing than things like offline commits, which are touted everywhere and more of a convenience than a new way of working.

Subversion is great for propagating a working environment on multiple machines, and backing up against disaster. But you’re right that it gives no help at all for intelligently using all the information it safeguards for things like relocating bits of text within and between files, observing the timeline of changes, etc..

In general, I am astonished how poor word processing tools are for large complex documents. It’s too hard to get an overview of a document structure, to zoom in/out, to describe and save chunks of text for insertion later, to see visually how a document changes over time, to save associated assets (figures, etc.) in an orderly way. Latex Reftex is a pretty good combo, as are Scrivener markdown, but it all feels quite jury-rigged. There’s a long way to go.