[V3dot10] Case Study 1 (Answering Milan from needed Tool
peace_the_dreamer at yahoo.com
Wed Jan 24 06:44:10 UTC 2007
Case Study 1:
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
|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
|such "stealing" was one of the problems Stef and
Marcus ran into, but I do
|not remember that from reading the post mortem
|I must be wrong, but I'd like to understand how such
situation is dealt with
Bored stiff? Loosen up...
Download and play hundreds of games for free on Yahoo! Games.
More information about the V3dot10