Publishing on Monticello

stéphane ducasse ducasse at iam.unibe.ch
Sun Sep 18 08:41:20 UTC 2005


>
>>>
>>> Like being able to get (only) the hot spot methods presented,  
>>> the  overrides whose originals changed in the meantime, so that  
>>> they are  now not overriding anymore what they did when being  
>>> programmed.
>>>
>> See above (or my previous message to Stef) - MC will highlight  
>> these  methods for you.
>>
>
> You seem not to understand that there are different "perspectives"  
> of working with Squeak. That is what I tried to distinguish in my  
> original message with:
>
> - developing the master line
> - developing a parallel master line and try to sync it partly to  
> another master line (Tweak, Croquet)
> - developing private stuff and keep it in sync with some master line
>
> For the first two tasks MC is well suited, but they are performed  
> by only a few, like you. Here you change something in your image,  
> the master, and every now and then you merge in a MC-file from  
> someone else.
>
> 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.
>
> ...
>
>>> Yes, there is an interface problem. It starts with the bubble  
>>> help  repeating what the buttons "merge" and "load" themselves  
>>> say.  Unfortunately I don't know exactly what "load" and "merge"  
>>> means,  so I can't send you code ;)
>>>
>> "Load" discards your own changes and loads the new version.  
>> "Merge"  preserves your local modifications and applies changes  
>> done since the  "fork" (where your version and the other version  
>> diverged).
>>
>
> That seems to be a good start for changing the bubble help text.  
> But it shows again that MC has been developed from a specific  
> perspective, a perspective most don't have, and that MC developers  
> are not aware of that. The devil is in the details here, e.g. I  
> think the more precise description for "load" would be that not  
> only your changes are discarded but the whole package gets replaced  
> as if it were wholly discarded first.

I often disagree with martin, but for once I think that for his  
scenario he is right. :)
Martin have you tried to implement the behavior you describe in MC  
because it would be a useful add-on.
And yes we should change the label and bubble of the buttons.

Stef






More information about the Squeak-dev mailing list