<diegogomezdeck at consultar.com> wrote:

> Hi Stef,
> 
> We suffered exactly the same problem with MCP and we "solve" it with
> scripts that get the list of removed classes (from the changesets) and we
> create a second changeset with the modifications we made to the removed-
> stuff.
Sounds an interesting approach - tell us more!
> 
> We spent a *lot* of time to do that.
> 
> One possible solution is to create more tools for our work.
Tools are almost always worth the effort once you know what you want
them to do. Even though tools to help with removal&cleanup might seem to
have a limited lifespan I suspect they would pay off in less frustration
and better code.

One relatively simple tool I can see a use for is just the set of
scripts to produce the currently dropped out packages; not the removal
of the code, which we already have but the production of the stuff to
file back in. If we had a decent collection of those available, the kcp
& mcp etc folks could load all the packages, do their cleanups and then
dump out replacement versions of the packages. Then at least we have
some artifact that can be compared to see what differences exist and
thus we can decide if it means a replacement of the package or an update
to the package.

I swear the FileContentsBrowser used to be able to load two files and
compare them but it doesn't seem to do that now. 
> 
> The other solution is to pause the removals for a while.
That isn't at all a ridiculous idea, so long as we are making good
progress in cleanup work. We do have to face the fact that major
cleanups will cause much chaos and consternation. As long as we can
gather as much of it as possible into one orgy of reconstruction and
then create a stable base for a while it should be worth it.

tim
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
BREAKFAST.COM halted... cereal port not responding!