Why do ChangeSets sort?
Andrew C. Greenberg
werdna at mucow.com
Wed Feb 19 12:11:59 UTC 2003
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
> 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.
> 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
> 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
> that don't exist? How do I make one remove a method from a
> that might not exist in some version?
More information about the Squeak-dev