Hi Marcel,

You were away when we had some discussions, so you missed some good analysis:

> <offtopic> Anyway, there is no such thing as "garbage version in the
> ancestry". This is not George Orwell's 1984 where people dictate or rewrite
> history. History becomes what has happened. If a database (back-end) or
> algorithm gets confused with this kind of events, then that database has to
> be fixed. Not the data. :-) Just my two cents. </offtopic>

I get you.  I've liked the freedom to shoot-from-the-hip and then just
go back and fix it since years ago when doing so got me in trouble
with "dev process" police.  It feels natural, and a fit for us and our
dynamic system.

But, "the database" must be carried by all current and
future Squeak users.  Every unnecessary commit bloats everyone's
current and future image files, including in RAM, and every future
.mcz file after that one, of which there are multple copies of each
(package-cache, etc.).  Add up all that duplication, and single one 2K
commit quickly becomes a 2MB impact to every current and future Squeak
users HD, RAM and network transportation.  Forever.

So how can we "fix" this?  I proposed the MCInfoProxy solution several
years ago, but that only addresses the in-image portion, and it wasn't
well-received anyway.

I think Dave's new "Reparent" button is the best go-to right now.
That way, we can have the cowboy-style dev process want and then
"squash" out the interim versions into one pretty version that
concisely describes the final product.

We have the squeak-dev archives which records our history, but
Squeak's ancestry entries should contain just the development
artifacts that emerged, but not the abandoned ideas too.  Imagine how
easy the next release  notes will be to write...

 - Chris