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 _______________________________________________ gnumeric-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnumeric-list
