[Modules] change sets vs. packages/modules

Allen Wirfs-Brock Allen_Wirfs-Brock at Instantiations.com
Thu Sep 6 16:04:51 UTC 2001


At 07:21 PM 9/5/2001 -0700, Joerg Beekmann wrote:
>I don't believe the concepts of change-sets and packages should be mapped. 
>I believe the concepts are orthogonal. Change
>sets collect the changes which transform a body of Smalltalk code from one 
>state to another. Up to now that body of code
>has been the entire image. Packages on the other hand define a body of 
>code. One could imagine associating a change set
>with a package. That change set would define the difference between the 
>current state of the package and its original
>state.
>
>Joerg

Joerg is correct, in concept.  There is a duality between a sequence of 
package versions, and a sequence of deltas that capture the changes between 
each version. From either you can derive the other. This is how source code 
control systems such as RCS or CVS achieve "compression".  They store a 
base version plus the deltas necessary to reconstruct any other version.

The problem is that Squeak change sets are not really deltas. As Paul 
McDonough pointed out , while packages are declarative specifications of 
their contents, change sets are imperative operations upon an 
image.   There is an obvious mapping from some of the imperative statements 
to declaration as they would appear in a package.  However, other 
imperative statements that commonly show up in change sets have ambiguous 
mappings. This means that existing change sets can not be reliably used as 
deltas in all situations.

The real solution to this would be to upgrade change sets to use the same 
set of declarative definitions as used in packages. This would eliminate 
the ambiguities that cause the problems.

Deltas ("change sets") can be very useful and I would highly recommend 
their inclusion in any development environment. The important thing from a 
version management perspective is that they capture what the programmer 
did, not how he did it.

Allen





More information about the Squeak-dev mailing list