On 10.08.2009, at 01:36, Andreas Raab wrote:

> Hi -
>
> I have noticed several times that Monticello sometimes reports a  
> different order of class variables than the one that's in the image  
> and I think I finally found out what causes it. The problem seems to  
> be that the MCClassDefinition is constructed from a Set of class var  
> names (i.e., Delay classVarNames => a Set(#TimerEventLoop  
> #SuspendedDelays #TimingSemaphore #ActiveDelayStartTime #ActiveDelay  
> #FinishedDelay #ScheduledDelay #RunTimerEventLoop #AccessProtect)  
> derived from the class' classPool.
>
> The thing is, the order in that class pool can differ. When you add  
> or remove class var names, the names can get shuffled around and  
> there is no telling what the exact enumeration order will be. Once  
> the order is different it's a real pain because Monticello will  
> always report differences but without a way to correct the issue.
>
> I'm wondering what possible fixes might be. In particular  
> considering that reordering the class var names will mark any  
> packages dirty for the same reasons.
>
> Any ideas?


Fix: Monticello-bf.281 (29 August 2006, 12:05:21 pm)
- ignore order of class vars and pools when comparing class defs

This version is missing in the trunk version ancestry, but present in  
the latest at

	http://www.squeaksource.com/mc.html

We should switch, but I have not tested how that version works with  
the updating process.

- Bert -