[V3dot10] Case Study 1 (Answering Milan from needed Tool

[Jerome Peace]

Hi Milan:

Case Study 1:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-July/106030.html
How NOT to move a group of methods to a new package in
5 minutes or less.

Yours in service, --Jerome Peace


 |> They ran 
|> into a number of problems using MC.  Nevertheless,
they succeeded, and
|> their opinion is that we should go forward and
improve how MC is used
|> rather than go back to change sets.
|
|Well, for what's worth, I like Monticello very much
and I feel Changesets are 
|too low level (but are more "powerful")... I feel
with Monticello 
|one "potential problem" comes in a situation like
this: There is a method 
|MyClass>#myMethod. It belongs, according to
Monticello naming, to MC Package 
|MyPackage. The someone writes a new application, the
new application belongs 
|to Monticello Package NewPackage, and New Package
decides to modify 
|MyClass>#myMethod, and add a line into it. (To me,
this is scary, but it 
|seems hapenning.) . How does Monticello deal with
this? It can "steal" 
|MyClass>#myMethod and make it part of NewPackage (by
changing it's method 
|category), but then that breaks MyPackage. If
NewPackage does not "steal" the 
|method, how can it "claim" that one line change for
itself? Perhaps 
|such "stealing" was one of the problems Stef and
Marcus ran into, but I do 
|not remember that from reading the post mortem 
|http://www.iam.unibe.ch/~scg/Archive/Papers/Denk07aErcimEvolutionSqueak.pdf
..  
|I must be wrong, but I'd like to understand how such
situation is dealt with 
|in Monticello.


 
____________________________________________________________________________________
Bored stiff? Loosen up... 
Download and play hundreds of games for free on Yahoo! Games.
http://games.yahoo.com/games/front