Hi Eliot,


Eliot Miranda-2 wrote
>> On Oct 4, 2020, at 6:14 PM, Jakob Reschke <

> forums.jakob@

> > wrote:
>> 
>> In other ways, Monticello just looks simpler because something is in fact
>> missing. Consider branches: most Git tools have knobs to deal with them
>> in
>> various ways, while Monticello tools just deny to talk about branches.
>> Monticello ancestry does support branching, yet I think Monticello lacks
>> first-class objects for branches, with all the implications for
>> repository
>> handling. The tools might look simpler without branch management, but it
>> is
>> not a feature but rather the lack of one. Note that you can also avoid
>> branch management in Git: just stay on the mainline branch forever and
>> merge
>> your commits back and forth with the upstream repository's mainline.
>> While
>> it might appear simpler that way, you might as well call it less
>> organized.
> 
> Monticello supports branches.  And merging between them is as easy as
> merging any other version of a package.  And Monticello does support
> recording histories across branches.

That is what I wrote: Monticello ancestry does support branching. But there
is no list of branches and there is no object for a branch. Instead one has
to find the loose ends in a sea of versions. Chris's first tool suggestion
would alleviate this, but it may be quite expensive and would still not give
names to branches.

Anyway, to have branches was not what Christoph and I were after. Topic
tracking and integrated conversations it is.


Eliot Miranda-2 wrote
> The two things that Monticello has over git are
> - that it is used without leaving the image.  I’ve yet to see a git
> integration where at some stage one was forced to try and fix things in
> git, or that the image and the git repository got out of sync, or that if
> one tried to use more than one image against a git repository something
> horrible broke
> - that it can be extended using our own tools.  Git is written in C and
> controlled by a separate community.  One gives up great autonomy when
> allowing ones core VCS to be in a foreign system.  When git crashes it
> crashes.  It doesn’t raise a friendly debugger in which one can determine
> and fix and proceed from the bug, it segfaults, in optimized code, and
> you’re hosed.

I can see your point. Although I cannot remember seeing Git crash for me in
the last ten years. And we are in a serious lock-in if we extend this notion
to everything in the world. I'm glad the other programming languages did not
all have to implement their own VCS first, otherwise there would be even
more of these around.

Luckily, we already have a Git implementation in Smalltalk. Thank Tobias for
urging me to salvage this rather than concentrating on FFI and libgit2 three
years ago. The Git Browser tools are as Squeak as they can be for dealing
with Smalltalk packages. Except maybe that the Git repository is still
stored outside, but what is a commit worth if it gets trapped in an unsaved,
unexpectedly broken image.

Even if we didn't have this Smalltalk implementation, the canonical Git has
lots of plumbing tools that could be controlled via OSProcess to query and
manipulate repositories. It wouldn't crash the VM like errors in libgit2
might, at the cost of being much slower.


Eliot Miranda-2 wrote
> Personally I don’t want to work in that kind of world.  The Pharo crowd
> do.  I will do everything in my power to prevent Squeak going the same
> way.  And if I’m unsuccessful I’ll go somewhere else.

Understood. I don't wish to see you leave.

Yet in my opinion Squeak really needs to get along with the outside world
for the mutual benefit; we cannot afford to always reimplement everything in
Smalltalk just to be able to comfortably debug the issues we wouldn't have
if we had used something mature.

Originally this thread was about the development process and how it can be
improved. Sorry for drifting into the Squeak vs. the World discussion again.
Some things just trouble me and make me sad.

Kind regards,
Jakob



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