Hi,
I have another comment on something that might be obvious about changesets.
But since I've been bitten by it (twice i think), it may not be so abvious to a newbie.
The point is: changesets don't capture the state of a method when it (i.e. the fact that the method changed) was last added to the changeset. They capture the fact that a certain method was changed and then on fileout add the current state of that method. Same goes for class changes.
This means you can't keep two changesets that contain incompatible changes to the same method in one image. Allthough such a tool would be really easy to write.
To illustrate my point here is what you can't do:

-Create and activate a change set named 'foo'
-Add a method named #bar to Object (change goes to cs 'foo')
-Create and activate a change set named 'baz'
-Remove method Object>>bar from system
And expect the two changesets to differ (other the #addedThenRemoved vs #deleted flag but fileouts will be the same).

A VersioningChangeSet would differ from a changeset in that it saves the source pointer of the method (and only updates it when the method changes during the active phase of that changeset -- or by explicit cleanup). 

HTH,
Torge

Ian Piumarta wrote:
> 
> On 22 Aug 2002, Konrad Hinsen wrote:
> >
> > So I suppose it is the programmer's task to define what goes into
> > a change set?
> 
> I'm going to answer this from a slightly different angle to the two
> replies I've seen so far (since I can't quite figure out from which angle
> the original question was asked).
> 
> Stuff goes into a change set automatically.  Whenever you make a change,
> that change gets logged and inerted into the current change set.
> Automatically.  You don't have to do anything explicit to "define" "what"
> goes into the change set: everything goes in.
> 
> > On what level do change sets work? Class, method, code line... ?
> 
> All of the above.  (Changes to methods, no matter how minimal, are
> considered as a completely new definition of the method.)
> 
> Looking at this from the other angle: change sets normally work on the
> project level.  When you create and enter a new project, that project has
> its own change set into which changes made in that project are logged.
> Projects remember to which change set changes made within them should be
> logged, so things don't get confusing if you work on several thing in
> several different projects.
> 
> You can, however, use a "change sorter" to change the "active" change set
> (the one into which changes are logged in the current project) at any
> time, and to delete any changes that you think are no longer relevant.
> There is also a "dual change sorter" which you can use to move/copy
> changes between change sets.
> 
> In summary: change sets do almost all of the work of preparing a
> "distribution" of whatever you're working on, without you having to do
> anything explicit beyond a little "tidying up" using a change sorter just
> before you file-out the finished gizmo.
> 
> Sorry if all of that was obvious.  I just thought that maybe the question
> might have been coming from "another direction".
> 
> Ian