Hi Folks.

Regarding reversible fileins, Dan Ingalls [Dan.Ingalls at disney.com] wrote:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"First, although, as Dwight points out, a fileIn can have any kind of
executable code in it, most are pretty well behaved (add/remove methods,
instVars, classVars, classes), and most of these changes could be reversed
without a huge amount of bookkeeping.  It might be worth doing." 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Good point!  As a person that often uses the filein mechanism, I would
suggest that "normal" fileins (fileins that don't execute any wild new code)
are far more prevalent than the latter.  I'm not a change set expert, but
isn't it the case that the executable code performed during the filein
process is stored in the post script section of the change set?  It might be
easy to mark change sets as "those containing executable code" and "those
without executable code" by doing a quick parse of the post script section
of the change set.  Having armed the change set browsers with the ability to
differentiate between the two cases, one could then allow the change sets
that do not execute wild new code to be removed from the image.

Of course, the process of reverting a change set out of your image would
require that you have not compressed your sources since the change set was
filed in.  It may also be the case that change sets that remove classes and
class variables may have to be disallowed from the reversion process.  After
all, what would you initialize the "deleted" class variables to?

This is interesting food for thought (it's lunchtime on the US east coast!).


Cheers!
---==> Chris
>