scm-like change tracking in gnumeric

[Brandon Casey <casey nrlssc navy mil>]

Hi,

Has anyone considered the idea of adding full SCM-like revision tracking to
gnumeric?

I have found traditional change tracking to be lacking when working with
spreadsheets.

I have recently begun using git to manage my source code and I am very
impressed with its flexibility.

Why shouldn't spreadsheet revision tracking have these capabilities:

    -snapshot the current state of the spreadsheet and record a message
     describing what was done and why. (i.e. commit)
    -select a limited set of cells to track
    -checkout an older state of the spreadsheet.
    -checkout a selected range of cells from an older spreadsheet state.
    -revert the changes made in a previous commit.
    -'diff' two spreadsheet states
    -No limitations on the allowed operations while tracking.
     e.g. Other spreadsheets disallow deleting, moving, splitting, and
          copying cells while tracking, and mergin, and deleting sheets.
          These operations should not be restricted.
    -"real" merging.
        -If I modify some cells and another user modifies different cells,
         and then I attempt to merge, it should produce a clean merge with
         both sets of changes.
        -If I move a cell, and another user modifies the function in that
         cell, the merged spreadsheet should contain the modified function
         in the moved location.
        -If I change the name of a sheet, and then merge with another user,
         the new spreadsheet should merge cleanly with the updated sheet name.

        -Conflicts should be marked for a human to resolve. In some "document"
         merging procedures a priority is given to one version or the other,
         so that changes from the higher priority version take precedence over
         the other version in the case of a conflict. A human is not given the
         opportunity to adjust the merge in progress.

These are all things that modern scm's provide.

Traditional spreadsheet tracking allows you to keep track of each individual
change to each cell. But many times, especially when you're dealing with a
complex spreadsheet, it is the net change to many cells which produces a single
logical change worthy of recording.

For example, updating or introducing a new algorithm may require modifying many
cells in order to implement. The intermediate states are not very interesting,
but I _would_ like to make a commit for the final result and record a message
describing the new algorithm and why it was necessary or how it improves over
the previous algorithm.

Possibly later, I may decide that the old algorithm worked better than the new
one. I should be able to revert the commit in whole.

Does anyone else find this idea as interesting as I do? Any thoughts on the
feasibility?

I haven't done more than salivate at the thought of being able to track
changes in my spreadsheet as easily as I can track changes in my source
code.

-brandon