You can choose (or not) to associate a change set with a project, etc. ....

Try Ned Konz's excellent and beautiful connectors project on Bob's 
SuperSwiki. It comes in as a project with a nice tutorial, but also 
adds the connectors functionality to Squeak.

Cheers,

Alan

------

At 8:59 AM -0400 8/1/02, Kevin Fisher wrote:
>Good point!  To be honest, I haven't tried saving my projects yet...I
>need to give this a try!
>
>As usual, I'm behind the rest of the class. :)
>
>
>
>On Thu, Aug 01, 2002 at 05:52:01AM -0800, Alan Kay wrote:
>>  How about projects?
>>
>>  That's what we and the children use ...
>>
>>  Cheers,
>>
>>  Alan
>>
>>  ------
>>  At 8:34 AM -0400 8/1/02, Kevin Fisher wrote:
>>  >Hi Folks:
>>  >
>>  >I've been wondering about something lately...how are people on this list
>>  >deploying Squeak applications?
>>  >
>>  >The way I see it you can do it one of two ways:
>>  >
>>  >1) An image per application, with all the changesets for the application
>>  >pre-loaded into the image.  If you've got a lot of Squeak apps though,
>>  >this can get rather space-hungry (given the size of the image+changeset).
>>  >You can go through the shrinking routine, and perhaps modules will help
>>  >shrink things down as well.
>>  >
>>  >2) A single image.  You have shell scripts/batch files written up for
>>  >each application, that fires up the Squeak VM with the stock image, and
>>  >loads a pre-made initialization script into the image on startup (which
>>  >then loads whatever is needed for the application).  The obvious problem
>>  >with this is if you've got an application that uses a LOT of changesets,
>>  >it could take a while to file them all in.
>>  >
>>  >3) A compromise between 1 and 2.   You have a single image.  When you have
>>  >a new application, you pre-load the changesets into the image.  Then you
>>  >have a set of run-time scripts that activate the right objects for your
>>  >application at startup.
>>  >
>>  >Is there a better way to do this?
>>
>>
>>  --
>>


--