Henrik,

> >>
> >> Since doits are not allowed in the module code, how do you go about
doing
> >> things in that have been traditionally done in a changeset's
postscript?
> >

>
> - Give DeltaModules pre- and postscript annotations. Not an unreasonable
> solution.
>
> We have all grown used to doing
> pretty advanced/nasty things as part of our normal coding.
>

This would be useful, at the very least, for migration purposes.

> I'll admit I haven't written it to handle
> successive change sets that modify the same classes/methods. Can you
explain
> why you don't do it all in one change set? That will help me give a
sensible
> suggestion.
>

In part, it's for historic purposes. Here's what happens:

I break up my project into seperate pieces (so I don't have one big
multi-megabyte changeset). As each changeset is read in, different "base"
parts of the system are changed. Because each chunk acts independently, I
don't rely on the entire system being available all at once. In my case (the
Zurgle project) I create new window frames. Then I create scrollbars, then
buttons, etc. At any point along the way I can stop and have a working
system. Typically as each part is read in, it changes the same area of a
base classes (e.g. SystemWindow initialize changes in several different
changesets ).

The other part has to do with the nature of Squeak development. Lets say I
write a project for Squeak 3.1. As time passes, and the Squeak codebase
changes, rather than change the underlying code of my project, I tend to
just write code to intereact with the new changes introduced in Squeak as
each version comes along. That way I end up with different versions of my
project that are incremental in nature. So I'll end up with changesets like
"Post-4643" and "Post-4743". If you run my project, say in a pre-4643, you
just don't file in files that are posted after the version that you're
using. As a consequence, sometimes I may have to define the same methods
several times in successive changesets. Later, I condense these together as
an 'official' release, like the day when Squeak 3.2 becomes blessed.

My real concern with the current scheme is that I've filed in code that I
can see in a browser, but it doesn't work as I would normally expect.

>
> I think the best solution will be to allow modules to specify "extra
files"
> to be filed in. This will allow various fringe cases to be handled more
> reasonably.
>

I like this solution

Thanks for all the work and time that you're putting into this,

Jim