[squeak-dev] Package commit granularity vs. Project commit granularity (was: FileStreams Limit)

Jakob Reschke jakres+squeak at gmail.com
Sat Feb 19 11:07:56 UTC 2022


Dear Jörg, dear all,

Am Sa., 19. Feb. 2022 um 10:54 Uhr schrieb Jörg Belger <unique75 at web.de>:
>
> If somebody thinks know to use Github as source code repository, I like the idea only a little bit, Pharo uses it. It has the advantage that nobody needs to run an own server at home :-)
> But the big disadvantage is, that you cannot think anymore in packages with its own version history like in Monticello. You need to think in repositories and branches and if you change two packages that are linked to one Github repository and you commit the first package, then I think you commit the second package too under the same version, because in reality you do not commit the package, you commit your current repository from disk to server. You lost the possibility to version each package differently.  That makes it impossible to load later packageA with version 1.5, but loading packageB with version 2.7.
>

To be honest, I do not see the problem here. Smalltalk version control
systems almost all offer the feature of configuration maps because it
is often required to specify which package versions work together
because the packages in fact belong together. In Git and similarly
organized version control systems, simply every commit is a
configuration of the packages contained therein. If you do not change
packageB on your new commit in which you want to change packageA,
packageB in that new commit will be equal to packageB in the parent
commit. It will not make a difference for packageB from which of the
two commits you load it, so why care?

If you want to grab a change to one package from a commit but not a
change to another package in the same commit -- for whatever reason
that the maintainer apparently did not have in mind -- simply make a
selective load/checkout: deselect the changes to the other package
that you do not want to apply to the image, just as you would deselect
changes that you do not want to commit when you create a new commit.
Or the other way around: browse the commit from which you need some
changes, select the package/category/class which you want, and load
just that.

If the two packages are really not connected to each other and it is
supported to freely combine different versions of them, then there is
no point to develop them on the same branch or even in the same
repository.

> Does anybody knows if we can have a Github repository where we can think like a Smalltalker and commit single packages ?

It is just a matter of organizing it as such. Create a new GitHub
repository for each package and commit only one package to each
repository. The repositories are already organized under your
username. For everything beyond a single person, there are GitHub
organizations like https://github.com/squeak-smalltalk/. If you want
to stay within a single Git repository for some reason, create a
separate branch for each package and only commit a single package on
each branch.

Kind regards,
Jakob


More information about the Squeak-dev mailing list