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
|