Hi Folks.

Regarding reversible fileins, Dan Ingalls [Dan.Ingalls@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