Correcting falsehoods in tech documentation, lessons learned

Version control of tools.

Over the years, this has come up on and off again. Some people fervently saying that tools should be kept in version control as well, some people saying that’s ridiculous overmanagement, and that many tools are very unhappy in version control anyway. For instance, try keeping a working version of visual studio in your version control system[1] Or even just try keeping different versions of a perl library from CPAN around.

I’ve normally leant somewhere in the middle. writing C? you probably want your compiler versioned. Nothing worse than an OS upgrade providing a new version of GCC and you finding that either a) it doesn’t compile any more, or b) worse still, some obscure “feature” has changed/been fixed. and your code compiles, but doesn’t _work_ anymore.

Writing Java? You probably want to always use the newest JDK. Writing perl? well, who knows….

Anyway, I ran into this problem recently with exiftool, or Image::ExifTool, depending on how you use it. Some changes/corrections in the library broke a lot of my photo gallery generation scripts. I did want some of the things in the newer versions of exiftool, like extended support for the MakerNotes for my new(ish) Canon 500D, and more robust parsing and writing of XMP.

What I didn’t want was changes to the IPTC print format. (Urgency was now returning “0 (reserved)” instead of “0”, I now needed Urgency# to disable print formatting) What I didn’t want was apparent changes to the priority of IPTC and XMP. What I wanted was my tools under version control.

Or more accurately, better acceptance testing of new tools before allowing new versions to be installed. But really, this is for home use. Do I really want to have a test suite run before I install any new tools? Hell No. But can I afford to let untested tools near my photos? No again.

Lose lose for the consumer. Like normal.

BACK TO POST Although, really, your version controlled tools should not require human intervention to build, so if you use visual studio to do the actual real builds of your system, you probably have other problems.