The Trunk: EToys-mt.368.mcz



Indeed, Git has its scalability problems as well. That's why Microsoft is developing "VFS for Git"  https://vfsforgit.org/ to address these issues, so they can use it for the massive Windows code base without being blocked by Git. Compared to that code base and its number of concurrent developers, Squeak and its ancestry are tiny, there should be no problems at all. And yet we argue regularly about saving space and time by folding a few Monticello versions together.

While the "laws of software physics" do apply to Git as well, Git still performs much better under their constraints than Monticello. I think people like to call that "more efficient". Monticello's abstract design may be nice, but its current approach to storage (which should be an implementation detail) is not. To make things worse, independent from Monticello, "how to store Smalltalk code in a file system" is another efficiency discussion as we can see in the opinions about the Tonel format.

Git never stores two equal objects twice (in a single repository, of course). Monticello does so happily with 90%+ of the snapshot and ancestry every time you press Save.

This technical shortcoming should be addressed. But it should not drive us to abandon sane diffs, which means separate commits for separate objectives.

Am Do., 21. Nov. 2019 um 21:48 Uhr schrieb Chris Muller <[hidden email]>:

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.

Nonsense.  You haven't magically escaped the laws of software physics.  You were using github, which is run in a datacenter, right?  Dump enough into your git repository, and your use-cases will eventually start to slow down in performance.

I am curious how you're "using git" though because when I accessed a git project through Squeak, it was NOT fast, and it created a gigantic directory tree in my squeak directory which also slowed down my daily backup job tremendously.  The directory names were hugely long and it was problematic.

This is why I won't start actively using git until I can make a transparent MCGitRepository via their v4 API (GraphQL).  I haven't looked at the Schema yet, but I wouldn't be surprised if it, alone, is larger than the entire _implementation_ code of Monticello.  I'd say Avi's was a brilliant design, for sure.

 - Chris