Re: scm-like change tracking in gnumeric

Hi Brandon,

you have very nicely summed up the features that a modern spreadsheet should offer.

I touched myself some of these features in a similar post on the website, see:
(especially the Track Changes paragraph) and

Indeed, tracking only some of the cells is a fundamental feature for tracking changes in spreadsheets.

Also, it is needed to track changes in the computed values, NOT the cell content per se.

Your additional suggestions offer really new insights into multiple ways of improving existing spreadsheet 



PS: Original message attached to this e-mail is
intended for the OOo mailing list

-------- Original-Nachricht --------
Datum: Fri, 01 Feb 2008 15:09:54 -0600
Von: Brandon Casey <casey nrlssc navy mil>
An: gnumeric-list gnome org
Betreff: scm-like change tracking in gnumeric


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

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
         merging procedures a priority is given to one version or the
         so that changes from the higher priority version take precedence
         the other version in the case of a conflict. A human is not given
         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
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
logical change worthy of recording.

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

Possibly later, I may decide that the old algorithm worked better than the
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

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


gnumeric-list mailing list
gnumeric-list gnome org

GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung:

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]