"Quality of the ancestry" to me _includes_ separating "piddly" things from
real, unrelated functional changes.

While the version list does grow with what you call noise, it keeps this
noise out of the diffs. That is priceless.

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.

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
commitlogsfromlastnight.com). On the other hand I can always quickly skip
"Reformat code" in the list of versions.

Sometimes colleagues commit reformatting of whole files (not Smalltalk)
together with their actual changes. It is a nightmare for reviewers.

Kind regards
Jakob


Chris Muller <asqueaker at gmail.com> schrieb am Do., 21. Nov. 2019, 08:55:

> Dave,
>
> I think we've found basic consensus on this issue...
>
> Small commits do generate more noise,
>
>
> No they don't.  Size is unrelated to content / noise.
>
> but I find that it is
>> easier to read, assess, and manage the changes if the commits
>> are small. I have spent a good deal of time doing this for
>> http://www.squeaksource.com/TrunkUpdateStreamV3 and my perspective
>> is based largely on that experience.
>
>
>> If I were to point to something in need of improvement, I would say
>> that is the performance of our Monticello tools.
>>
>> I *love* having the MC change management directly in the image where
>> everything is directly accessible, browseable, and minimally dependent
>> on external tools. But I have to admit that the tools are slow.
>> Processing the update stream is slow, comparing versions is slow,
>> and reading packages is slow.
>
>
> 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.
>
> 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.
>
> And I strongly suspect that if all of
>> these things were instantaniously fast, then none of us would care
>> about how big or small the commits were.
>>
>
> 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.
>
> 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.
>
> 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.
>
>
>>
>> I may be wrong, but I have to suspect that some profiling of common
>> use cases, such as updating Squeak from the server, might identify
>> some huge opportunities for improvement.
>>
>
> There's a bug with the "Move to Treated" that I think is an easy fix.  I
> would love if you would update squeaksource.com to the latest code and
> use that experience to find/fix any bugs that we can then backport to
> source.squeak.org...
>
>
>> But even if those improvements never happen, I think that small
>> commits are a good thing.
>>
>
> Well, I do hope you don't think splitting a single piece of functionality
> across multiple small commits is a good thing.
>
>  - Chris
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191121/72dc15de/attachment.html>