Version Control and Version Differentiation

I’d like to touch on two related subjects: issues with version control and certain “source” (not always human generated) files, and version control impacting development practices (and vice versa).

Most version control tools use line-by-line diffs because they are simplest and match most human-written source files well (they can determine just the few places where code was added or deleted and store only that difference) but generally don’t work ideally for swapped code (such as reordering functions), one of the two swapped pieces of code will be marked as deleted in one section and added in another, even if no major change occurred. Similarly, adding a new indent level generally deletes the old version entirely and adds a new version (while leaving the closing curly brace unchanged). These are faults of the diff tool not understanding the syntax of the language, but aren’t major nuisances and are largely ignored.

XML can completely break this simplistic heuristic because of how it is interpreted by programs. Technically by default whitespace is significant, and so is tag order, but not attribute order, but most programs do not care about whitespace significance in XML, and may or may not care about tag order, so each run through by a program auto-generating XML can produce wildly different text that represents the exact same data structure.

This can wreak havoc on actually determining what has changed per version and merging the changes of two users who used the same tool to update the XML file. (The same is true of any binary “source” like the Access ADP file.)

I don’t really see a solution for XML, since what is significant in the XML can vary from XML format to XML format, and even if you make a diff tool that understands DTD (or RelaxNG, or whatever validating format you use), how many people writing custom XML formats for their software actually demark insignificant whitespace as insignificant? And how do you even avoid the insignificant tag ordering? (I don’t think DTD lets you state such as insignificant.) It can only get worse for each binary format.

The only “solution” is a meta-language that describes the changes you make to such file formats and keeping the actual file outside of version control and reconstructed from these change sets (similar to managing a database schema with version control), but that can also get ugly quickly, and some of these changes may not be reversible like everything inside of the version control system (such as DROP DATABASE…).

Like I said, I don’t know of a solution to this problem (or I’d be looking for VC funding :-).

As far as version control and development practices, it’s a fairly symbiotic relationship there, but the most exciting (to me) is the recent introduction of git and github. It’s taking the open source software development paradigm (many disparate programmers across the world collaborating simultaneously on a single project [which Agile is very similar to a microcosm of such software development practices, in my opinion]) and “supercharging” it by reducing the barrier to contribution (both in getting the source onto your computer to modify and in getting the changes in a form “upstream” can accept) to just the coding ability of the developer interested in the project, while not undermining the authority of the originating project (unless it goes unmaintained, in which the forks fight for supremacy, as usual).