As a workaround, you can manually edit the changesets.

On Monday, February 17, 2003, at 09:03 PM, Richard A. O'Keefe wrote:

> 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?
>
>