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
|