[MC] Disabling overrides?

> Hi Folks -
>
> I just screwed myself so unbelievably badly by running into all the  
> evilness of using overrides in Monticello that I'm starting to  
> believe in ripping them out of MC alltogether. As a first step, I'd  
> like (just for my own sanity) to disable them in a way that makes  
> override categories behave just like regular extension categories  
> (e.g., both marking the original package as dirty and not trying to  
> restore anything when loaded). What's the easiest way to achieve that?
>
> Thanks,
>   - Andreas
>

> andreas
>
> can you give us an idea of your problem because we could get the same?
> What I know is that alex wrote tests showing that unloading a package
> with overriding was not restoring the correct hidden
> methods. But I'm not sure.
>
> Stef
> On 5 avr. 06, at 08:52, Andreas Raab wrote:
>
>> Hi Folks -
>>
>> I just screwed myself so unbelievably badly by running into all the
>> evilness of using overrides in Monticello that I'm starting to believe
>> in ripping them out of MC alltogether. As a first step, I'd like (just
>> for my own sanity) to disable them in a way that makes override
>> categories behave just like regular extension categories (e.g., both
>> marking the original package as dirty and not trying to restore
>> anything when loaded). What's the easiest way to achieve that?
>>
>> Thanks,
>>   - Andreas
>>
>
>
>

> One was something along the lines of:
> - Load package A
> - Load package B that has an override in A
> - Check package A for changes (there are none)
> - Publish package A
> - Start over, load package A
> - Note that the overridden methods are gone
> With a few additional twists and permutations of updating  
> individual packages in the mean time.
>
> The other one was along the lines of:
> - Load package A
> - Load package B that has overrides
> - Note that some stuff in package A is broken
> - Check package A for changes (there are none)
> - Wonder WTF is going on...
>
> I think this is partly an awareness issue. To me, it's equally  
> important to know whether a package has been modified by an  
> override or whether it has been modified by changing code  
> otherwise. The assumption that a package remains unchanged by an  
> override is just plain wrong.
>
>   - A.
>
> stéphane ducasse wrote:
>> andreas
>> can you give us an idea of your problem because we could get the  
>> same?
>> What I know is that alex wrote tests showing that unloading a  
>> package with overriding was not restoring the correct hidden
>> methods. But I'm not sure.
>> Stef
>> On 5 avr. 06, at 08:52, Andreas Raab wrote:
>>> Hi Folks -
>>>
>>> I just screwed myself so unbelievably badly by running into all  
>>> the evilness of using overrides in Monticello that I'm starting  
>>> to believe in ripping them out of MC alltogether. As a first  
>>> step, I'd like (just for my own sanity) to disable them in a way  
>>> that makes override categories behave just like regular extension  
>>> categories (e.g., both marking the original package as dirty and  
>>> not trying to restore anything when loaded). What's the easiest  
>>> way to achieve that?
>>>
>>> Thanks,
>>>   - Andreas
>>>
>
>

>>>>> I just screwed myself so unbelievably badly by running into all
>>>>> the evilness of using overrides in Monticello that I'm starting
>>>>> to believe in ripping them out of MC alltogether. As a first
>>>>> step, I'd like (just for my own sanity) to disable them in a way
>>>>> that makes override categories behave just like regular extension
>>>>> categories (e.g., both marking the original package as dirty and
>>>>> not trying to restore anything when loaded). What's the easiest
>>>>> way to achieve that?
>
> I would say: just don't use overrides.