<div dir="auto"><div>"Quality of the ancestry" to me _includes_ separating "piddly" things from real, unrelated functional changes.</div><div dir="auto"><br></div><div dir="auto">While the version list does grow with what you call noise, it keeps this noise out of the diffs. That is priceless. </div><div dir="auto"><br></div><div dir="auto">Monticello duplicating megabytes of data for every new version is a serious flaw and should be addressed. Fix the system, not its users. Adopt a new storage format, deduplicate ancestry nodes and definitions in memory, whatever.</div><div dir="auto"><div dir="auto"><br></div><div dir="auto">Low quality history to me would mean that things are hard to find or recover. That means huge commits that do a dozen things at once or commits with useless messages like "fixing stuff" (or pick your favorites from <a href="http://commitlogsfromlastnight.com" rel="noreferrer noreferrer noreferrer" target="_blank">commitlogsfromlastnight.com</a>). On the other hand I can always quickly skip "Reformat code" in the list of versions.</div><div dir="auto"><br></div><div dir="auto">Sometimes colleagues commit reformatting of whole files (not Smalltalk) together with their actual changes. It is a nightmare for reviewers.</div><div dir="auto"><br></div>Kind regards</div><div dir="auto">Jakob</div><div dir="auto"><br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">Chris Muller <<a href="mailto:asqueaker@gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank">asqueaker@gmail.com</a>> schrieb am Do., 21. Nov. 2019, 08:55:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr">Dave,</div><div><br></div><div>I think we've found basic consensus on this issue...<br></div><div dir="ltr"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Small commits do generate more noise, </blockquote><div><br></div><div>No they don't.  Size is unrelated to content / noise.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">but I find that it is<br>
easier to read, assess, and manage the changes if the commits<br>
are small. I have spent a good deal of time doing this for<br>
<a href="http://www.squeaksource.com/TrunkUpdateStreamV3" rel="noreferrer noreferrer noreferrer noreferrer noreferrer" target="_blank">http://www.squeaksource.com/TrunkUpdateStreamV3</a> and my perspective<br>
is based largely on that experience. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If I were to point to something in need of improvement, I would say<br>
that is the performance of our Monticello tools.<br>
<br>
I *love* having the MC change management directly in the image where<br>
everything is directly accessible, browseable, and minimally dependent<br>
on external tools. But I have to admit that the tools are slow.<br>
Processing the update stream is slow, comparing versions is slow,<br>
and reading packages is slow. </blockquote><div><br></div><div>It's a database, Dave, it responds to the laws of software physics.  Any database, including a strictly file-based one like we're using (not Magma), will perform more slowly as you put more objects into it.  It's unavoidable and why, as it grows, you want the highest percentage of objects in it to be meaningful.  Whether a large revert, or a small one-line comment fix, inconsequential objects become the noises that dilute the value of any database.</div><div><br></div><div>But all that is subordinate to the fact that the MC ancestry is _the_ artifact we make and put out and resides on all of our computers.  This makes it something to not carelessly ignore like the typical black-hole log file.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">And I strongly suspect that if all of<br>
these things were instantaniously fast, then none of us would care<br>
about how big or small the commits were. <br></blockquote><div><br></div><div>No, that's exactly backwards!  The truth is that _even if_ it were instantaniously fast, we all should still care about the quality of the ancestry.</div><div><br></div><div>Like I said, I think the recent commits have suggested consensus, no complaints here.  Maybe a bit small'ish for my taste, but Marcel is keeping the packaging (version description) comparably terse too.  It adds up to clear and meaningful unit-of-change.</div><div><br></div><div>There's always going to be _some_ noise, but we seem to be doing better.  With new people, it can be a good time to remember.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I may be wrong, but I have to suspect that some profiling of common<br>
use cases, such as updating Squeak from the server, might identify<br>
some huge opportunities for improvement.<br></blockquote><div><br></div><div>There's a bug with the "Move to Treated" that I think is an easy fix.  I would love if you would update <a href="http://squeaksource.com" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">squeaksource.com</a> to the latest code and use that experience to find/fix any bugs that we can then backport to source.squeak.org...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
But even if those improvements never happen, I think that small<br>
commits are a good thing.<br></blockquote><div><br></div><div>Well, I do hope you don't think splitting a single piece of functionality across multiple small commits is a good thing.</div><div><br></div><div> - Chris</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote></div></div>
<br>
</blockquote></div></div></div>