The Inverted Repository 

I was recently napping during a conference on Data Centre Management  when I was aroused by a students simple question to the speaker.

"How should we version control configurable items like UNIX property files" (e.g. /etc/hosts).

The lecturer suggested that a version control tool like CVS should be installed on the server and that the engineer should check the files into the repository before a change. Mmmm ... a plausible answer I guess. But to be honest its not exactly streamlined, nor is it 100% practical.

The problem is many DC (Data Centre) engineers work across networks, sites and organisations. Imagine installing a version control tool every time you changed a server configuration. Mmmm that's the end of our SLA's.

As I contemplated, I started to recognise a problem. CM Tools are built for S/W engineers i.e. There heavy, there super functional and there goal is to be centralised (one server, 100's of clients).

The irony is DC engineers often need the opposite i.e. a portable CM tool that fits on a floppy, installs in a second & lives on each local machine (distributed). The bottom line is they don't really care about merging, they don't really care about workflow. All they want is a transparent way to record there local changes and have the flexibility to roll back to Point-X if it all screws up. 

Dare I suggest that DC engineers require an "Inverted Repository".

Copyright © 2002 SnuffyBear Company (Sydney Australia).