On 4/7/2010 7:58 AM, Edgar J. De Cleene wrote:
> On 4/6/10 1:38 PM, "Andreas Raab"<andreas.raab at gmx.de>  wrote:
>> What I really don't understand here is why you think that it's easier to
>> do that with change sets rather than Monticello. I've merged lots of
>> systems and before Monticello this was an insanely painful process. I
>> found that with Monticello this became almost reasonable; still
>> difficult but no longer outright insane.
>
> Take fresh 4.0.
> Unzip this in same folder and filein first PrepareFor311Updates.3.cs
> Now you could update local with
> "Utilities applyUpdatesFromDisk" using real .cs
> Or "Utilities updateFromServer" load from trunk and made this NUMBERED .cs
> from the first day, not several updates later.
> Also the update number change.

But why is any of this advantageous to using Monticello? I'm not arguing 
that you can't do what you describe but from my perspective it is 
disadvantageous because:

1) You loose the ability to describe what is included in the image at 
each stage. A change set is not a package, consequently there is no good 
way to describe what is in an image at any given stage and whether the 
contents is "correct".

2) Monticello handles conflicts, change sets do not. If I maintain 
images that have modifications to certain methods, Monticello will tell 
me that there's a conflict and allow me to decide how to resolve it.

3) Monticello provides context, change sets do not. I can merge versions 
in the inbox and see what changes are done, and if they conflict with 
changes before or after.

4) Monticello now uses (semi-)atomic loading, change sets do not.

*All* of these are killer arguments in my view.  The first one says that 
I can hit the "changes" button for any package that looks modified and 
find out if I do have local modifications or if the contents of the 
package is the same as in the corresponding Squeak version. I don't need 
to have a "virgin" image around just because I don't know if the image 
at hand may have modifications.

The second one says that I can update without the fear of destroying any 
of my work. In the past, when we used update streams I have had several 
location where an update nuked parts of work that I was just doing.

The third one says that the work of an integrator is much simplified. 
You can merge changes without fear of having conflicts even if you merge 
a distant or old version of a package.

The last one says that I don't need to test (and manually edit) load 
order in many situations that you had to before. Since method 
installation has been tidied up modifying methods in the compiler is no 
problem any longer. Change sets still suffer from this.

Really, I fail to see how anyone can reasonably claim superiority of 
change sets for what we're doing at this point.

Cheers,
   - Andreas