Jim Benson wrote:

> 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.
> 

This is what I guessed from my own experience. So here it makes some sense
to treat each step/chunk as a separate submodule. When we have versions you
could handle them as such and automatically let later ones have earlier
versions as prerequisites. But now I recommend you to use separate
submodules, Zurgle Part1, Zurgle Part2, Zurgle Post4643 and so on. They will
be brought in in the order you define them.

Use the importer separately for each of these submodules to bring them in
correctly. Then you simply store and load the "mother module" Zurgle and all
of these will be brought in as part of it.

> 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.

The importer is limited in scope and this is a consequence of that.

Henrik