Monticello and overwriting a selector temporary

>
> There is another practice which is far from "best". It's only  
> slightly less evil than modifying other packages. It causes headaches  
> in the long run. It depends on the Monticello and PackageInfo  
> version. You should not use it but stick to the best practice. And  
> definitely do not use it for anything you want to share. You have  
> been warned. This practice is called "overrides", and works by moving  
> your method into a "*mymodule-override" category. This lets  
> Monticello know this is a temporary override and it will try to  
> restore the original method when you remove it from your package - it  
> relies on a proper version history in the changes file for that. This  
> is highly unreliable in most but the very simplest cases. Did I  
> mention you should not use it, unless you *really* know what you're  
> doing? And don't come back and complain ;)
>

>
>>
>> There is another practice which is far from "best". It's only
>> slightly less evil than modifying other packages. It causes headaches
>> in the long run. It depends on the Monticello and PackageInfo
>> version. You should not use it but stick to the best practice. And
>> definitely do not use it for anything you want to share. You have
>> been warned. This practice is called "overrides", and works by moving
>> your method into a "*mymodule-override" category. This lets
>> Monticello know this is a temporary override and it will try to
>> restore the original method when you remove it from your package - it
>> relies on a proper version history in the changes file for that. This
>> is highly unreliable in most but the very simplest cases. Did I
>> mention you should not use it, unless you *really* know what you're
>> doing? And don't come back and complain ;)
>>
> Oh, well, I can read between the lines that this is a good approach
> to do :) All I can understand is that in my case it only can do
> less harmful changes. I haven't tried but it looks like _exactly_
> what I was looking for. And I will convince a lot of other people
> to use it, too. :))

> On May 24, 2007, at 12:29 , Norbert Hartl wrote:
>
> >
> >>
> >> There is another practice which is far from "best". It's only
> >> slightly less evil than modifying other packages. It causes headaches
> >> in the long run. It depends on the Monticello and PackageInfo
> >> version. You should not use it but stick to the best practice. And
> >> definitely do not use it for anything you want to share. You have
> >> been warned. This practice is called "overrides", and works by moving
> >> your method into a "*mymodule-override" category. This lets
> >> Monticello know this is a temporary override and it will try to
> >> restore the original method when you remove it from your package - it
> >> relies on a proper version history in the changes file for that. This
> >> is highly unreliable in most but the very simplest cases. Did I
> >> mention you should not use it, unless you *really* know what you're
> >> doing? And don't come back and complain ;)
> >>
> > Oh, well, I can read between the lines that this is a good approach
> > to do :) All I can understand is that in my case it only can do
> > less harmful changes. I haven't tried but it looks like _exactly_
> > what I was looking for. And I will convince a lot of other people
> > to use it, too. :))
>
> Even with the smiley I did mean what I wrote. Overrides have caused a  
> lot of subtile problems in several projects we did, and if something  
> goes wrong, it is impossible to remove them except by manually  
> fiddling with the version history in each image that this has been  
> loaded into.
>

> On Thu, 2007-05-24 at 12:56 +0200, Bert Freudenberg wrote:
> > On May 24, 2007, at 12:29 , Norbert Hartl wrote:
> >
> > >
> > >>
> > >> There is another practice which is far from "best". It's only
> > >> slightly less evil than modifying other packages. It causes headaches
> > >> in the long run. It depends on the Monticello and PackageInfo
> > >> version. You should not use it but stick to the best practice. And
> > >> definitely do not use it for anything you want to share. You have
> > >> been warned. This practice is called "overrides", and works by moving
> > >> your method into a "*mymodule-override" category. This lets
> > >> Monticello know this is a temporary override and it will try to
> > >> restore the original method when you remove it from your package - it
> > >> relies on a proper version history in the changes file for that. This
> > >> is highly unreliable in most but the very simplest cases. Did I
> > >> mention you should not use it, unless you *really* know what you're
> > >> doing? And don't come back and complain ;)
> > >>
> > > Oh, well, I can read between the lines that this is a good approach
> > > to do :) All I can understand is that in my case it only can do
> > > less harmful changes. I haven't tried but it looks like _exactly_
> > > what I was looking for. And I will convince a lot of other people
> > > to use it, too. :))
> >
> > Even with the smiley I did mean what I wrote. Overrides have caused a
> > lot of subtile problems in several projects we did, and if something
> > goes wrong, it is impossible to remove them except by manually
> > fiddling with the version history in each image that this has been
> > loaded into.
> >
> That's also true for the "not temporary" overwrites. I know it is
> bad but If I need a quick fix for something "possible" useful the
> risk is there. If I do category changes for foreign projects the
> method is gone anyway and I have to load it again from the original
> source. So I meant if using such things than the temporary override
> is less harmful than the permanent.
> But I recognized that saving a new version of a module doesn't mean
> I have to publish it :) This seems much more clever than stomping on
> other peoples code.
>
> Btw. methods can have versions and classes don't. Is there any reason
> for this or just never done?
>
> thanks,
>
> norbert
>
>
>