[squeak-dev] ancestry vs. log
asqueaker at gmail.com
Wed Dec 5 19:55:50 UTC 2018
> > ... 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
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