Hi Dave,
I think you are being a bit too invasive here. Trying to rewrite the version history after the fact is usually a bad idea (*) unless it is an emergency situation in which someone has inadvertently broken the update stream. That was not the case here, and Tobias had already taken the appropriate action to revert the method.
Deleting a version is a valid use case and one of those things we just have to deal with occasionally. It's not invasive, nothing was rewritten, and it's a very good idea.
Aside from emergencies, I think it's better to leave the version history as it is, warts and all. If this results in our tools and/or update stream being too slow, then let's work on fixing that problem.
With all due respect, please review our recent discussion [1] about this where I explained how it's about more than update stream being too slow... it will save me a lot of (re)typing.
I would offer the counter suggestion of let's work on our consideration and respect for the trunk repository, and Squeak's code model, so these cleanups are not necessary in the first place.
(*) Among the unintended consequences of modifying the version history after the fact is that it makes a mess in one of my own projects (http://www.squeaksource.com/TrunkUpdateStreamV3). I will untangle it, but I would be happier if I didn't need to.
*I* had to do an untangle. You may be able to simply relax and do nothing with that -- when a new Collections is published, you'll have a couple of orphans? Better to have litter there than in our public-facing /trunk history/.
As I said before, hopefully it won't happen very often, but if it does, I re-affirm my promise to try to keep unnecessary litter from forever bloating the ENTIRE ecosystem. However "miniscule" it may seem, please understand
- it affects all dimensions: Disk, RAM, CPU, Network, and Lists in the IDE - for all users - for all time, forever.
That's more cost to Squeak than I can bear for a brain fart.
Regards, Chris
[1] -- See thread: "This is the Help System failure..."