Hi Chris,

I was mainly offering my opinion based on my on experience tending
to the (unnofficial and private) www.squeaksource.com/TrunkUpdateStreamV3
which involves a good deal of reading, reviewing, and merging.

I can happily admit to another bias as well - I have been using
git for a while now (nothing related to Smalltalk), and I have to
say that it is a revelation. It is powerful, complex, and adaptable
from the outside, and on the inside it is nothing but simple. It is
also very, very fast.

So it turns out that good versioning tools do not need to be slow
and resource hungry. I guess it also shows that a small amount of
brilliant design goes a long way when it comes to performance.

Dave

p.s. No, I am NOT advocating use of git for Squeak (I'm not against
it either). But it is an existence proof that things do not have to
be slow and inefficient. Meanwhile, I continue to be very happy
with Monticello, it's really quite wonderful IMHO.

On Thu, Nov 21, 2019 at 01:54:22AM -0600, Chris Muller wrote:
> 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

>