"Richard A. O'Keefe" <ok at cs.otago.ac.nz> wrote:

> I've now spent some time digging into the change set implementation.
> It's actually one of the better documented parts of Squeak.
> The use of dictionaries to hold things means that reordering is a
> fundamental aspect of the way it currently works.
> It looks like a fairly major overhaul of change sets to make them
> record the only order which is actually KNOWN to work.

That order is *not* known to work.  You may have done some doits along
the way.  You may have redefined a class one way and then redefined
another.  You may have, half-way through, loaded something from
SqueakMap.  You may have painted a picture and then stashed it in a
class variable.

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.

That would be overkill.  Changesets should only solve the lesser problem
of isolating a chunk of code you have changed.  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.

That said, I do feel your pain.  :)  If you look at the list of
changesets for Islands, you'll see a lot of things like foo1.cs,
foo2.cs, foo3,cs, where I manually separated a sequence of changes into
separate changesets.  It's a special pain when later versions of the
changeset rewrite methods that are in earlier ones, because if I file
them back *out* again it will use the "new" version.  Arg!  Still,
compared to the effort of *finding* a good sequence of changes,
separating the changes into separate changesets is nothing.


Lex