Re: scm-like change tracking in gnumeric

[txtedmacs <hcohen05 gmail com>]

Perhaps I am unsophisticated, however, my question is why duplicate what 
is done better and more efficiently in a version control system? What 
about the childre....n, ah no, I mean what about the code bloat and 
performance degradation that will result? Given the other response where 
this person cites his suggestion to do the same in OpenOffice, seems a 
particular bad place. A common complaint about OO.o is its lack of 
performance. So you want to make it worse? [I am not complaining, 
despite using an older version, but others do complain loudly.]

If you are able to use git a distributed (with the potential to work off 
line) version control system, why not get yourself some thing just a bit 
less difficult to run your versioning? Indeed, I am impressed due to my 
reading complaints about git, which lacks good documentation compared to 
the competitive distributed, version control systems. Moreover if stored 
on another disc on another machine or even a remote server, should you 
lose your present machine for any reason you could rebuilt your spread 
sheets at any stage. The latter seems a good reason not to bundle 
another feature not everyone will appreciate. If you disagree, where is 
the exceptional gain by bundling this ability?


Brandon Casey wrote:
> 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
>
> _______________________________________________
> gnumeric-list mailing list
> gnumeric-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnumeric-list
>
>