Hi,

Now I do not know to which message to reply first :-) and unfortunately most
of this is again not about the development process, but at least it is about
the experience.

I prefer Git over Monticello not only because Git is more wide-spread and
has platforms available to support it. I marked some key points in bold in
the following paragraphs in case you cannot afford to read all of it. Sorry
to those on plaintext mail clients.

*You can track more objects with Git* (or any unspecialized VCS) *than with
Monticello.* As you confirmed Eliot, you cannot track files in Monticello.
You also cannot track a Morph or a Readme in Monticello. Instead we need to
squeeze everything into classes and methods. You can track anything with Git
that you can transform into a tree of blobs. Including Smalltalk code, it is
just a special case. Want a new kind of MCDefinition? Git does not care and
will store it for you, whatever it is. Monticello, not so easy. (In the end
in both cases you would probably have to write some kind of de/serialization
to get something nice, but in Monticello you have to modify the VCS, whereas
for generic systems you would extend "above" the VCS.)

Using *Git does not imply that you have to use tools outside of the image*.
And it does not mean to "be less Smalltalk". Eliot, you asked what I would
do if I had unlimited resources. I would improve the Git Browser and
accompanying tools so that one could do everything as comfortably as with
Monticello, and yet be able to do more than Monticello allows. Well,
depending on who you ask, the new tools have already surpassed the
Monticello tools in some usability aspects, but certainly not in every way.
;-) But what I meant to say here is that *the long-time Monticello user
should be able to feel "at home" even though the repository is a Git
repository now*. Regarding the integration of code review, conversation etc.
and the tracking of contributions, which got us going here, one can probably
build this all in Squeak. There have been projects going in this direction
in the past, right Tobias? ;-) With unlimited resources, I would also do
that in Squeak because unlimited resources, especially time, means that I
could patiently build all the middleware, connectivity, cloud-readiness and
OS integration stuff that are more present in the Java, .NET, JavaScript,
and Python ecosystems. Or I might try to give those other things more of a
Squeak experience, which is one of the things I like about the work Fabio is
doing about polyglot programming. Back to reality for now...

Of course *it is possible to have domain-specific tools on top of Git* (or
any other suitable, unspecialized VCS), to get a "Monticello expericence"
(at least the good parts of it). "Git tools" do not need to stop at the
level of file trees and branches of them. I have not used IceBerg myself
Eliot, but it sounds like it is on the wrong level of abstraction for your
taste. We can have "easy" yet rich and powerful tools in the image with just
about any VCS, this is *not a conceptual monopoly of Monticello* (or at
least it doesn't have to be). So in my opinion we should go with the most
practical (to avoid saying "the best") VCS of the respective time. Squot is
built with a certain degree of agnosticism toward the kind of repository, as
long as it can store arbitrary objects. The Git Browser of course is
somewhat specific to Git, as the name tells. For one because of
Git-specifics like remotes, but also regarding the vocabulary on the buttons
("commit", "push", "pull"), to look familiar to Git users (of which there
are arguably more than there are Smalltalkers). But we could create a
different version of the tool that presents things differently, for sure.

I think a "real" Git backend for Monticello is also feasible, now that we
have a usable Git implemenation in Smalltalk already. That's why I brought
it up at all. But it would still be a compromise because *Monticello has
more quirks* than just being limited to the respective class hierarchy of
MCDefinition.

For one, there is this *awful implementation of storage* in Monticello, both
on the disk and in memory. What a waste to store the whole snapshot again
with each version. And how easy it is to have *a version in the middle of
the history missing* from a repository, which makes "diffy versions"
dangerous. Git's solution to that (but Mercurial would also be good enough
there) is much more space- and time-efficient. You might object that you
have to clone the whole Git repository (though there are ways out of that,
Microsoft's  vfsforgit <https://vfsforgit.org/>   being one of them), but
for the below-Enterprise-scale project it is just not a problem in Git!
Copying the whole history of Squeak Trunk on the other hand will probably
take longer than to clone an equivalent Git repository, and it will take up
more disk space.

Using Git as a backend could solve the efficiency problem in the repository,
but *without core changes to Monticello itself, there would still be waste
in the image*. This is the reason why we are asked to compress history
through less granular commits and contribution reshaping. Quite
extraordinary how our tool shapes our process! To refactor this for the
better would mean to increase the complexity of Monticello, though. Just as
Squot is definitely more complex than Monticello if you count all of Squot's
parts (by the way, Squot still uses Monticello for package capturing,
loading and image patching, but not the Monticello tools and not the
ancestry implementation).

Then there is the delineation of a project. In Monticello, you have to save
each package of a project separately. And you may have to create a
configuration map on top of that. *In Git* (or just about anything else)
*you would just have multiple packages in the tree and save them all
together*, and each commit constitutes an implicit configuration of the
packages. I think this is a *tremendous advantage in usability*. Many
projects consist of more than one package. Yet most of the time the -Core,
-Test, -Fluff packages evolve simultaneously. This flaw of Monticello as I
am willing to call it is at the core of its model, and therefore also its
tools! ("Whew, does anyone remember which version of System corresponds to
the changes in this Kernel version...?", because the System version didn't
have a number yet when the Kernel version was saved, and therefore was not
manually !!! referenced in the log message.)

We already talked about branches. VMMaker is surprisingly just one package,
therefore it is easier to create branches through the naming conventions of
packages or versions. *Imagine you would have to care about the branch
suffix for three or five, let alone 12 or 50 packages* to create and manage
a branch of a project. Well, you could create a branched configuration map,
but good luck for not letting stuff that belongs to the branch slip into a
package that didn't initially get the new naming. Most of the time it seems
easier to branch in Monticello by creating a separate repository to hold the
branch. This is also something I would consider for a real
Git-in-Monticello: to create a branch, create another repo (with the same
Git backing); to "push", copy from a local repsitory to a remote repository
(and also copy the ancestors along because everything else would be
pointless); to merge, well merge the version from the other repo, be it
local or remote. Yet this betrays the concept of a repository if you have
multiple instances of the same one on your list of repositories. So it still
feels like a workaround, just like relying on version name or package name
conventions feels to me. I think this is where Eric Evan's book of
Domain-Driven Design calls for "Making an implicit concept explicit".

One might also say  that branches are not a good idea anyway
<https://trunkbaseddevelopment.com/>  . That there should only be feature
flags or really-short-lived branches that are quickly reviewed and then
merged. But to have only short-lived branches without the overhead of actual
branch management, *we would need better tools to track contributions and a
commitment to process them quickly*! The last part might not be feasible
even if we had the tools, because you currently cannot earn a living from
maintaining and supervising Squeak Trunk development. And about feature
flags: I hear we have too many preferences already? ;-)

Now hitting "Post Message" before it's 3 a.m. again...

Kind regards,
Jakob



--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html