[squeak-dev] Squeak and Tonel

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Thu Feb 14 22:15:23 UTC 2019

I think that we should at least support the input/output of tonel packages
for inter-operability.
Since the git repositories are metadataless, we can't do much more without
a lot of work.

Since tonel has no support for timestamps, it looses authorship (it is
replaced by committer-ship).
If we don't want to loose authorship, then we need to port whole history to
git with known initials <-> git(hub) account database.
This is currently working for single package with complex graph (to
filetree format, but could work for Tonel too).
If you want to commit several MC packages in same git repository, then it's
currently impossible to support complex history.
There is generally no information that enables inter-MC-package
synchronization (unless some sort of MCConfigurationMap is used, which at
least gives a few sync point in history...).

If we want to perform essential operations like commit/pull/merge or access
essential information as history/revisions/diffs then we have to
- either reproduce the very hard work that began in Pharo: program a git
client inside the image,
- or loose inside image tools.

Squeak MC tools are much more productive than Pharo MC tools:
- they scale well even for massive changes (i did check with auto generated
Smallapack interface)
- they support cherry-picking: you see and control what you commit
- they are quasi bugfree
- the magma backend provides a few additional features (revisions...)
Pharo team has produced huge effort for the github switch, but it does not
go without pain. Despite the importance of being visible on github, and
profit by state of the art web collaborating tools, i don't see Squeak able
to take this major turn in near future.

If we want to have mix development with packages maintained both in a MC
repository and a git metadataless repository,
then we have the problem of finding a common ancestor.
I think that this could be doable with some conventions (like storing the
.last_known_mc_ancestor in a file)
Of course, it's re-introduction of metadata, but the minimal possible, and
leads to easy to resolve conflicts (that can be automated)...

The last grief I have with Tonel is that it is not syntax agnostic.
Since we have a language where we can define compilerClass/parserClass,
that's unfortunate (The application i developed in the 90's did use such
important feature, it's not just theoretical)
It could have been language agnostic with very little effort (remember the
discussion on Pharo-dev, just using an arbitrary number of [[[   ]]] as
method body separators would suffice)
For most packages, that will not be a problem though.

Le jeu. 14 févr. 2019 à 15:17, Torsten Bergmann <astares at gmx.de> a écrit :

> Hi,
> as some of you might already know "Tonel" is a file-per-class format for
> monticello repositories [1].
> In Pharo land many projects are already converted to it - as regular "file
> tree" solution faces issues
> with git handling due to very long file names / deep file hierarchy (often
> leading to trouble on Windows).
> Dales's Rowan (a new project/package manager for Smalltalk) supports
> FileTree and also Tonel
> repositories [2]. There is also a tool to convert from STORE (VisualWorks
> Source-Code Versioning System)
> to Tonel format [3].
> So I wonder about adoption of Tonel in Squeak land.
> Any status/comments?
> Thx
> T.
> [1] https://github.com/pharo-vcs/tonel
> [2] https://github.com/GemTalk/Rowan
> [3]
> https://pharoweekly.wordpress.com/2019/01/20/ann-sett-store-export-to-tonel-tools-for-pharo6-1/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20190214/fc848659/attachment.html>

More information about the Squeak-dev mailing list