[squeak-dev] ancestry vs. log

Chris Muller asqueaker at gmail.com
Wed Dec 5 19:55:50 UTC 2018

Hi Tobias,

> > ... snip ...
> > 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...
> I don't get it.
>   First, non-tunk users get none of this, Release images get only rare,
> severe updates. There's no influx of stuff. So, they're fine in the first place.

Wrong.  The ancestral model is stored in every one of their images.

>   Second, trunk users are to be aware that trunk is, well, trunk, bleeding
> edge, you name it. When something breaks, tough. There's no promise. And I don't
> think there should be. So trunk users are fine by definition.

But, per "A New Community Development Model", breaking it is "frowned upon".

This is actually off-topic, but I agree that trunk users are tough, so
there's nothing "dangerous" when someone cleans a 5-minute old,
self-admitted mistake.  If someone wants to be upset, direct it toward
the bad committer, not the cleaner please!   ;-/

>   Third, the "database bloat problem". I don't frankly see it. That's because of
> two things. First, updates are handed out as mcd's, severely cutting down the size of
> transported data. Second, for a given MCZ, the ancestry size is quite unimportant.
> It's merely a (pretty darn good compressible) string. So resource-wise we're a-ok,
> I'd say.

Zoom-out from looking at only your single-user self and consider the
other 3 dimensions of resource impact within the Squeak universe.  I
described this several times before:
> > 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, it's kind of like a "tax".  As an individual, you may not feel it
since its spread out, but that does not mean the impact is not real.
It's just a slow-creep, like a frog in a pot...

> You state "Squeak's ancestry entries should contain just the development
> artifacts that emerged, but not the abandoned ideas too." and I strongly disagree.
> Let's not get down the rabbit hole of bending the process to the tools. Rather, the
> other way round.

The process and tools are tightly-integrated, there is no "the other
way round" but you could make some suggestions or get behind the ones
being floated.

I cannot stop you polluting the trunk ancestry, I can only ask or try
to clean up after you.  Obviously, I could maintain my own, but that
would only help me, not Squeak.


More information about the Squeak-dev mailing list