[MC] Disabling overrides?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[MC] Disabling overrides?

Andreas.Raab
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

Reply | Threaded
Open this post in threaded view
|

Re: [MC] Disabling overrides?

stéphane ducasse-2
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
>


Reply | Threaded
Open this post in threaded view
|

Re: [MC] Disabling overrides?

Andreas.Raab
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
>>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: [MC] Disabling overrides?

stéphane ducasse-2
I see thanks for the scenario.

Stef

On 5 avr. 06, at 19:40, Andreas Raab wrote:

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


Reply | Threaded
Open this post in threaded view
|

Re: [MC] Disabling overrides?

Lukas Renggli
>>>> 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. This is simple and does not
need any further work. Monticello is very strong at merging, so my
policy is to fork all external packages and to do necessary changes
directly in there. Later on you can easily update the external
packages by merging back in the latest versions. This practice works
much better for me than using overrides.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

Reply | Threaded
Open this post in threaded view
|

Re: [MC] Disabling overrides?

Avi  Bryant

On Apr 5, 2006, at 1:29 PM, Lukas Renggli wrote:
>
> I would say: just don't use overrides. This is simple and does not
> need any further work. Monticello is very strong at merging, so my
> policy is to fork all external packages and to do necessary changes
> directly in there. Later on you can easily update the external
> packages by merging back in the latest versions. This practice works
> much better for me than using overrides.

I second that.  Overrides simply aren't worth the complexity they bring.

Avi

Reply | Threaded
Open this post in threaded view
|

Re: [MC] Disabling overrides?

Andreas.Raab
In reply to this post by Lukas Renggli
Lukas Renggli wrote:

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

Works great for your own packages. Works not at all for packages done by
others. That's why I'm asking for a way to disable it so that at least
*I* can see where overrides have been used (I'm just not in the mood to
wade through hundreds of packages manually).

   - A.

Reply | Threaded
Open this post in threaded view
|

Re: [MC] Disabling overrides?

Andreas.Raab
In reply to this post by Avi Bryant
Avi Bryant wrote:
> I second that.  Overrides simply aren't worth the complexity they bring.

Okay. Then. How. Do. I. Turn. Them. Off. That's all I want to know.

   - A.