Managing node revisions with a backend like subversion?

looking around in the DB tables for my (4.6) drupal site using the dba.module, i noticed that drupal is currently doing something very ineffecient for storing the different revisions of each node. the "node" table just has a longtext field called "revisions", which contains serialized copies of the entire node for each revision. looking at the DB schemas for 4.7, i see that things have changed (there's now a "node_revisions" table), but it seems like once again, we're storing the entire node (with separate fields for the teaser and body) for each revision. for nodes with lots of text that are edited frequently, this becomes a huge waste of space in the database. while i haven't done any benchmarking, it's probably slow as hell to unserialize and process all that data once the number of revisions gets big, too (4.7 seems to have at least solved this part of the problem).

my first thought was "why doesn't drupal just record the diff in the DB, like most revision control systems do?"

then i had a (potentially) better idea... why doesn't drupal just use a real revision control system for this? it seems like a collosal waste of time for the drupal development community to reinvent a tool that other people have already made (a far more powerful and mature version of that tool than we've got, for that matter). wouldn't subversion itself be a nice fit for a backend to store the body of any node that has been configured to save revisions? the "revisions" field (or a row in the 4.7 node_revisions table) would just hold a new svn tag identifier for each unique revision of a node (tagging is nearly instantaneous in subversion, unlike cvs). since all nodes have a unique nid, we could use a simple convention for the filenames that each node's body were stored under. we'd still cache the most current revision in the node table, both for performance and for compatibility with all the existing modules and APIs. however, the parts of node.module that are trying to store or retrieve a given revision could just run some svn command(s) to either retrieve or commit and tag a given revision of a given node.

eventually (and i know this kind of proposal would actually be years from really existing within drupal, which is why i set the "Drupal version" to "none" for this post) we could ask the nice folks who develop subversion if they'd be willing to:

• make a version that uses MySQL as a backend instead of BerkeleyDB (they already must have a level of indirection for this, since they're now supporting both BerkeleyDB and the file system as the backend storage... seems like a MySQL backend is a logical next step for them, if it's not already in the works)
• provide a php API so that applications like drupal could just invoke this API to access the svn repository directly (instead of having to fork()/exec() svn command-line tools)

once drupal was using svn as a backend to store node revisions, it'd be trivial to provide all sorts of powerful node revision functionality within drupal ("blame annotated source", better viewing of diffs, diffs across arbitrary revisions, RCS keyword substitution on nodes... anything svn can do already). we'd save a ton of space in the DB, and we'd never have to worry about manually adding new functionality to our revision management system, since we wouldn't be maintaining one anymore.

is this totally crazy? (yes, i know i'm painting an overly optimistic picture) ;)
has this been discussed before? (i couldn't find anything like this searching the forums)
is any of this worth investigating?

i'm curious what everyone thinks about this.

thanks,
-derek