Hi Richard.

If what you want is history, undo and redo over all code changes by the
user, you can get that. Note that though ChangeSets have only the latest
of each, and out of order, the changes file has EVERYTHING. And the
mechanism that let's you see a method's old versions could certainly be
used to do things like unload a package (for each method, look up the
version that was used previous to the package's and reinstate it).

Note that I said package, not changeset. As you noted, CSes are not
suitable for this kind of requirement. Packages are. They're not time
lines. But the marriage of a disk based package + the changes file as
the images time line might be enough for what you want...

Daniel

"Richard A. O'Keefe" <ok at cs.otago.ac.nz> wrote:
> I wrote:
> 	"Richard A. O'Keefe" <ok at cs.otago.ac.nz> wrote:
> 	> It looks like a fairly major overhaul of change sets to make them
> 	> record the only order which is actually KNOWN to work.
> 	
> 	From: "Lex Spoon" <lex at cc.gatech.edu>
> 
> 	That order is *not* known to work.
> 	You may have done some doits along the way.
> 
> Yes, but in my book they count as changes and should automatically
> go in the change timeline.  It should require special manual effort
> to remove them.
> 
> 	You may have redefined a class one way and then redefined
> 	another.
> 
> Those changes already go in a change set; I can imagine no reason
> why they would not go in a timeline.
> 
> 	You may have, half-way through, loaded something from
> 	SqueakMap.
> 
> That's a change.  It should go in a change timeline.  It should
> require special manual effort to remove it.
> 
> 	You may have painted a picture and then stashed it in a
> 	class variable.
> 	
> That's a change.  It should go in a change timeline.  It should
> require special manual effort to remove it.
> 
> Basically what I'm saying is that the change recording machinery and
> the "undo" machinery should be the same machinery.
> 
> 	Yes, changesets offer a simplified view on the development
> 	process that leads to a chunk of code.  However, I can't think
> 	of a way to record the true sequence of events short of making
> 	an execution trace of the image while you were developing.
> 	
> You don't need to record all the events, just the manually entered
> "commands" which triggered them.
> 
> I would remind readers that Interlisp-D *had* infinite undo/redo for
> all manually entered commands, and very handy it was.
> 
> None of the above should be taken as a demand that someone else do it.
> Now that I thoroughly understand that a ChangeSet is a change *SET*
> and know what the limitations of the medium are, I can work within them.
> 
> My point is just that getting a lot closer to "record changes in time line,
> change history can then be played back" isn't as novel as it sounds nor as
> difficult.
> 
> 	That would be overkill.
> 
> Recording a full trace of every assignment, yes.  (Although there's a C
> debugger called Leonardo which does that.  Neat stuff.)  Recording
> user commands not only wouldn't be overkill, it wouldn't even be novel.
> 
> 	Changesets should only solve the lesser problem
> 	of isolating a chunk of code you have changed.
> 
> Why?  It isn't clear to me that doing what I want would be any harder.
> At least, not if you were developing a new Smalltalk from scratch.
> It's classic undo/redo.  I once had access to the source code of Interlisp-D,
> and the history stuff was not a huge percentage of the code.
> 
> 	If you need the code to
> 	be loaded in some specialized order, and/or if you need some do-its
> 	sprinkled in the middle of the reloading, then the generic changeset
> 	mechanism just *can't* help you, and we shouldn't bother trying.
> 	
> The changeset mechanism can't BECAUSE IT GOES OUT OF ITS WAY TO BE UNABLE TO.
> There is no reason why a "change history" mechanism *couldn't*, and the
> Interlisp-D one could.  (Albeit only within a single session.  Saving stuff
> out in files was different in Interlisp-D, not least because Interlisp-D
> did not actually load everything in a file in one linear pass.)
> 
> I repeat, I know understand better what ChangeSets are _intended_ to be
> useful for, and I'm not saying that they should now be altered to be
> change histories.  I'm just saying that a change history mechanism WOULD
> have been practical.
> 
> It's particularly relevant for things like eToys.  Being able to see a
> log of "what did I do that got me into this state" could be very useful,
> as could the ability to rewind to an earlier state.