The code<\/a> is from the Downloads area of my Atlassian Bitbucket<\/a> repository<\/a>; see the README<\/a> online.<\/p>\n VCSs like mercurial<\/a><\/i>, git<\/a><\/i> and bazaar<\/a><\/i> (to mention only a few) are great for keeping track of changes to source files, but their utility doesn’t stop there. \u00a0If you’re working on documents in applications like Word<\/i>, OpenOffice<\/i> or LibreOffice<\/i>, especially when you are asking others to review those documents, a VCS program can save you a lot of anguish.<\/p>\n However, people who work not with source code, but with research papers, academic assignments and the like, are not inclined to make themselves familiar with the tools that geeks have grown used to. \u00a0Considering how long it took for software developers to embrace those tools, it’s hardly surprising.<\/p>\n Unfortunately, VCSs aren’t set up well for managing such files. \u00a0They depend for efficient version management on tracking line-by-line differences in file. \u00a0This allows them to maintain the minimal set of changes from version to version, and to readily show what changes have occurred between any two versions. \u00a0That works well for source files, which are written in plain text, but not for files which maintain their own complex internal formats, which generally only become readable when translated by the “mother” application.<\/p>\n VCSs provide for such files, but they mark them as binary, and make no attempt to track the differences between them. \u00a0Instead, for each version, they simply keep a copy of the entire file. \u00a0While this is still better by a long stretch than not being able to track, version by version, the history of a document, it makes it impossible for the native VCS to show what the differences between versions actually were.<\/p>\n This problem has been partially addressed before. For those who generate Open Document Text (ODT) files with, for example, \u00a0OpenOffice<\/i>, the program\u00a0odt2txt<\/i><\/a>\u00a0will extract text from those documents. \u00a0odt2txt<\/i>, in turn, enabled\u00a0oodiff<\/i><\/a>, which is a script to generate a diff from the text of two ODT files, extracted with odt2txt<\/i>. \u00a0It’s not a complete solution, because there is still no merge facility, but it at least allows the textual differences between versions to be examined from within the VCS.<\/p>\n The combination of such a file comparison program with a VCS graphical interface presents a much lower barrier to adoption for users from outside the asylum. \u00a0Because I\u1fbdm on OS X, \u00a0I’ve been using Atlassian’s free product, SourceTree<\/a><\/i>, which has the advantage of working with both mercurial (hg)<\/i> and git<\/i>. \u00a0If you’re working with mercurial<\/i> only, or if you are on a linux distribution, you can use TortoiseHg<\/a><\/i> as a graphical front end.<\/p>\n That wasn’t quite enough, because my wife, whose requirements got me thinking about this, works mainly with Word<\/i> files. \u00a0I needed an equivalent of odt2txt<\/i> and oodiff<\/i> for both .doc and .docx files \u2014 which have very different formats.<\/p>\n Fortunately, the problem of extracting text from these formats has already been conveniently solved by the Apache Tika<\/a> project. \u00a0Tika can extract metadata, plain text, xml and html from a dazzlingly array of file types. \u00a0For my purposes, plain text and metadata will suffice; metadata only for any file types, like images, from which text cannot be gleaned. \u00a0Tika provides not merely a substitute for odt2txt<\/i>, but an extension to virtually any commonly (an many not so commonly) used file formats. All that remained was to provide a substitute for oodiff<\/i>.<\/p>\n That’s tikadiff<\/i>. \u00a0It takes either two filenames and generates a graphical diff of them, or two directories and, for each file in the first, generates a diff of the file of the same name (if it exists) in the second. \u00a0tikadiff<\/i> depends on Tika (obviously) and a graphical diff program; by default kdiff3<\/a><\/i>, but it is currently written to look also for Perforce p4merge<\/a><\/i>, and can be instructed to use a diff program of your choice, provided that it accepts the same two arguments.<\/p>\n tikadiff<\/i> depends also on a number of scripts that are distributed with it.<\/p>\n tika<\/i> is a convenience script to run the CLI from the tika-app jar file. \u00a0It passes all its arguments to tika-app. \u00a0In addition to that basic function, it will preset certain arguments to tika-app depending on the name by which it is invoked.<\/p>\n tikserve<\/i>, like tika<\/i>, is a convenience script to run tika-app. \u00a0Unlike tika<\/i>, it is not invoked (except during setup) under its own name, but only through a series of links. \u00a0It runs tika-app as a server, which performs some operation on any file which is written to its open TCP port.<\/p>\n In order to run the server(s), tikserve<\/i> needs a port on localhost. To support this habit, tikserve<\/i> looks to two other scripts.<\/p>\n freeport<\/i> hands back the next available port on localhost, starting at 1024. You may optionally give it a minimum port number and, sub-optionally, a maximum port number as constraints. \u00a0In order to perform this task, freeport<\/i> requires\u2014<\/p>\n localhostports<\/i>\u00a0prints the ports which, in the opinion of\u00a0netstat<\/i>, are currently associated with localhost.<\/p>\n Bitbucket\u00a0repository Downloads<\/a>; see the\u00a0README<\/a>\u00a0online.<\/p>\n<\/div>\nVersion Control Systems (VCSs)<\/h4>\n
Limitations of VCSs<\/h4>\n
Other solutions<\/h4>\n
Thank you, Tika<\/h4>\n
tikadiff<\/i><\/h4>\n
tika<\/i><\/h4>\n
\n
tikserve<\/em><\/h4>\n
\n
freeport<\/i><\/h4>\n
localhostports<\/i><\/h4>\n
Code, again<\/h4>\n