Publishing on Monticello

Avi Bryant avi.bryant at gmail.com
Sun Sep 18 08:52:26 UTC 2005


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.

Avi



More information about the Squeak-dev mailing list