Why do ChangeSets sort?
Richard A. O'Keefe
ok at cs.otago.ac.nz
Tue Feb 18 02:03:12 UTC 2003
I spent much of last night coding up and testing #collect:into:.
(Why so much time? Because of the need to check all versions of
#collect: in the system to make sure I wouldn't break anything.)
On the way, I found a number of interesting things.
For example, Path>>collect: and Path>>select:
were totally broken in Squeak 3.0 and 3.2. I have to assume that
nobody ever used them. The change set I am developing fixes them.
One of the nasty things when you are replacing parts of the core
is that you have to be *very* careful about the order you do things.
I discovered this the hard way, meeting the emergency evaluator for
the first time (and the second and the third and ... sigh).
We have
Collection >>collect:
SequenceableCollection >>collect:
OrderedCollection >>collect:
SortedCollection >>collect:
and you have to
(1) plug in the rest of the collect:into: framework,
(2) replace Collection>>collect:
(3) remove SequenceableCollection>>collect:
(4) remove OrderedCollection>>collect:
(5) remove SortedCollection>>collect:
If you do step (4) before doing step (3), it's emergency evaluator time.
Once I realised what I was doing wrong, I started up a fresh system,
loaded the new methods, and then did (2..5) in the right order. Hooray!
It all worked.
So I saved the lot as a change set, started up a fresh system,
loaded the change set, and HELLO EMERGENCY EVALUATOR!
Reason: the change set did not save the removal steps in the order I did
them, but in ALPHABETIC order! That moved step (4) before step (3) and
disaster predictably struck.
Q1: Why are change sets saved in alphabetic order rather than
chronological order? It seems obvious that this is likely to
break change sequences.
Q2: Is there any way I can tell change management to use chronological
order instead?
Q3: At the moment, I'm dealing with the problem by manually shuffling
the removal directives whenever I save a new version of the change
set. Is there a better way to do this?
Q4: I'd like the change set to be usable in 3.0, 3.2, and 3.4.
Is it OK if a change set file contains directives to remove methods
that don't exist? How do I make one remove a method from a _class_
that might not exist in some version?
More information about the Squeak-dev
mailing list
|