Why do ChangeSets sort?

Daniel Vainsencher danielv at netvision.net.il
Tue Feb 18 16:10:05 UTC 2003


When I care about this enough, I maintain separate changesets, to be
loaded in a specific order. No, that's not fun either, since there's no
automatic way to keep them disjoint. But if you keep them small enough,
it's easy enough to do manually.

Daniel

"Richard A. O'Keefe" <ok at cs.otago.ac.nz> 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?



More information about the Squeak-dev mailing list