Re: scm-like change tracking in gnumeric

[Brandon Casey <casey nrlssc navy mil>]

txtedmacs wrote:
> Perhaps I am unsophisticated, however, my question is why duplicate what 
> is done better and more efficiently in a version control system?

I don't think I understand you.

In order to use a version control system, I cannot use a spreadsheet.
Well, I can, but it doesn't get me anything more than just making
copies of the spreadsheet.

  $ <new spreadsheet>
  $ <edit>
  $ save my_algorithm.gnumeric
  $ <edit adjust algorithm to handle case 2>
  $ save my_algorithm_with_case2.gnumeric
  $ <edit add second algorithm>
  $ save my_algorithm_with_case2_plus_alg2.gnumeric

or some such. You could even add a version number in the name to encode
some progression.

If I use an external SCM to track that, I could avoid changing the file
name, and additionally add a commit message describing the change, but
that's it. The SCM would see each of those files as some binary blob
and would have no idea how they were related. It would be impossible
to merge changes from two collaborators, or to revert previously made
changes.

> What 
> about the childre....n, ah no, I mean what about the code bloat and 
> performance degradation that will result?

code bloat and children are always valid concerns. I expect this will
improve the usefulness of spreadsheets by increasing people's confidence
in them. This could be a modification to the "Track Changes" feature of
most spreadsheet programs which is only marginally useful.

Have you ever had a spreadsheet that grew so big you were scared to change
anything? Ever sent a spreadsheet to someone else, and got it back with
their changes, but now strange things happen? Ever changed a formula in
a spreadsheet and then 6 months later wondered why you implemented it a
certain way?

Similar things happen when developing source code, and we use SCM's to
help us out.

With the new powerful SCM's I can easily checkout different versions of
source code, merge changes from different developers, and revert previously
made changes.

These things need to be in the spreadsheet program since only that program
understands how the cells are related. Take for example the example I
mentioned before...if developer A moves a cell and developer B modifies
the formula in the same cell, when A merges B's changes, the moved cell
should contain the modified function. Or vice-versa, B's cells, referencing
the moved cell, should be updated during the merge.

I said "in" the spreadsheet program, but whether it is "in" gnumeric, or
whether it is a module, or something else should be suggested by someone
familiar with the internals.

> 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?

Performance is not affected by code that is not executed.

> If you disagree, where is 
> the exceptional gain by bundling this ability?

> >     -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.

-brandon