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

Ralph Johnson johnson at cs.uiuc.edu
Wed Jan 24 14:38:13 UTC 2007


On 1/24/07, Jerome Peace <peace_the_dreamer at yahoo.com> wrote:
> |I must be wrong, but I'd like to understand how such
> situation is dealt with
> |in Monticello.

I followed back to the original posts.  That is a great story!

In short, if Package1 requires a change to a method in Package2 then
you should NOT move the method to Package2.  instead, you should make
a new version of Package2 and Package1  requires that new version, not
the old one.  The problem is thiinking that "change" is the same as
"new version of a package".  Often changes cut across package
boundaries.

The worst is refactorings.  Suppose we decide to change the name of
the #add: method.  This is easy to do in the refactoring browser.  it
will require changine nearly every package, and if you use one of
these new versions, you will want to use them all.  In general,
version control systems do not deal well with changes to interfaces of
packages.

-Ralph


More information about the V3dot10 mailing list