anyone kicking around? I've just remember a problem a colleague of mine had at my previous workplace, and I'm in the mood to bang around ideas for solving it. It was pretty interesting.
Essentially, they were writing an application that helped manage different component configurations. I can't mention the actual domain, so let's say they were managing different configurations of plane parts on a plane. Certain configurations were good for low drag but bad handling, other configurations were good for handling but sacrificed speed.
The parts used in these configurations also changed versions, but that typically mattered less because different versions of the same part served the same function.
So, a flight team might have certain known configurations for certain flights which were tweaked for the demands of the flight.
The flight team, however, was always experimenting with different configurations, so it wanted a system to keep track of all past configurations and let them revert to them.
... and show diffs... and branch off from them.
My friend's team ended up writing their own versioning system with diffing, branching, mergin... everything you'd find in your typical source control.
But, because of the low volume of data (a dozen distinct flights per year, with dozens of configurations each, at worst), I always wondered if they should have just used a source control system to managed serialized versions of their configurations.
The "current" configurations could have always been kept in a database, or even in the server's memory to ensure a speedy system. And less frequent operations like diffs, branching, and merging, could have been done in source control programmatically by their server (albeit probably at a slower pace).
The Whiteboard
The Whiteboard