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 <
ma.chris.m at gmail.com>:

> 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191122/7b079ae9/attachment.html>