Why do ChangeSets sort?

Richard A. O'Keefe ok at cs.otago.ac.nz
Mon Feb 24 01:32:38 UTC 2003

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

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

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

	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.

More information about the Squeak-dev mailing list