>>So I'm arguing that the core functionality -- the definition of a Module (and/or component) -- is a unit of Stuff that I can remove.
>>Currently that means Class  or Category .    But ChangeSet does NOT meet this definition of Module.

Dan Moniz <dnm at pobox.com> responded...
>(Okay, I'm speculating wildly here...)
>
>But ChangeSets _could_, couldn't they, with some modification to the way they work?
>
>I'm imagining that when you file in a ChangeSet (let's say Foo.cs) into your image (Bar.image), your image is writing out information to it's Bar.changes file that reflect the things Foo.cs is doing to your image. Then, to back out, you could use a currently fictional "Undo" feature which would allow you to back up steps as recorded in Bar.changes
>
>This may necessitate modifications to userland tools to deal with .changes file, and perhaps some modification to the information and/or format of information stored in .changes files, but I don't think it would be too drastic and I don't think it would have much with the implementation of ChangeSets themselves.

Actually, there is a great deal of support for removal already in changeSets.  In fact, in the few milliseconds it takes to enter or leave an isolated project, all the changes get asserted and reverted.  This is done by saving a copy of the  method dictionaries and organizations before the changes.  This is expensive in space, but incredibly effective for reverting.  I can imagine a number of alternative solutions such as...

	using the file pointers to prior versions which would
		require some compilation before the revert.

The (incomplete) uninstall command to ChangeSets does this.

	saving the revert state in an image segment on file.
		You could load this quickly to do a revert.

Basically, I'm agreeing -- yes, ChangeSets could be made truly removable, especially in the context of a module architecture.

	- Dan
--