Publishing on Monticello

Bert Freudenberg bert at impara.de
Sun Sep 18 19:04:07 UTC 2005


Am 18.09.2005 um 10:52 schrieb Avi Bryant:

> On Sep 18, 2005, at 2:29 AM, Martin Wirblat wrote:
>
>>
>> The third task is the operation conducted by the overwhelming  
>> majority. Here a different working style is needed. You download  
>> some image, e.g. the newest release, an interim release or some  
>> special version of someone. Then you file your stuff in.
>>
>> For that case I would like to have a convenient and fast method,  
>> because that is what many people do. I would like to have one  
>> single package, the delta package that creates your private basic  
>> image, not many mcd-files. On loading or whatever that could be  
>> called I get a list with methods which override *and* the method  
>> they override got changed, compared to the one I originally overrode.
>>
>> MC will only give me a list of *all* overrides here. The best  
>> thing you can do with this list, is to manually check, whether the  
>> old and the new overridden method are the same or not. That's  
>> nearly impossible - you need to compare two images, your old one  
>> and the new one, for all the methods, one by one. Most people will  
>> refuse to do so and simply choose "load". They are not better off  
>> with MC than with the old changeset system.
>
> I think this is a documentation issue rather than an implementation  
> one.  It sounds to me like what you're describing someone having to  
> do manually is precisely what Monticello's merging is designed to  
> automate: checking for concurrent and thus conflicting changes to  
> the same methods. If "the old and new overridden method are [not]  
> the same", then the MC merge browser will display that change in  
> bold, and force you to resolve the conflict.
>
> As for having a single delta package, couldn't you have one top  
> level package that had dependencies on all of the various package  
> versions you want to load in?  That would then be a single-click  
> operation to merge in.
>
> In general, your claims about what MC was or was not designed to  
> support don't match what we thought our goals were when we designed  
> it.  So I'd like to find out where things are going wrong.

That's my impression, too. MC should be well capable of using it in  
this way - even though the merge UI could surely be improved .

- Bert -




More information about the Squeak-dev mailing list