[squeak-dev] Re: Edgar from the Ostracism Re: Squeak 4.1 release
andreas.raab at gmx.de
Wed Apr 7 16:12:33 UTC 2010
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
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.
More information about the Squeak-dev