<div dir="auto"><div>With these modest requirements, David, please try the port and open issues for anything that bugs you about it.</div><div dir="auto"><br><br><div class="gmail_quote" dir="auto"><div dir="ltr">Am Fr., 15. Feb. 2019, 02:14 hat David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> geschrieben:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Torsten,<br>
<br>
Thank you very much for asking about this, and thanks to Nicolas for the<br>
explanations.<br>
<br>
As a package maintainer (OSProcess and others), I want to be able to<br>
provide continued support for Pharo users, and it would probably be helpful<br>
if I could read and write to Tonel as an external format. I am also interested<br>
in being able to browse and read the projects (many of them quite excellent)<br>
that are being developed in Pharo from my Squeak image.<br>
<br>
I am a big fan of git, but I do not care about integrating it with the<br>
image (Squeak/Pharo) because I prefer using the in-image tools in Squeak,<br>
and when I do use git, I prefer to use git tools directly.<br>
<br>
I am not well informed about this topic, but overall I would say that being<br>
able to read and write Tonel format from Squeak would be very helpful, and<br>
I would probably not care very much about version control integration.<br>
<br>
Thanks again for asking,<br>
<br>
Dave <br>
<br>
<br>
On Thu, Feb 14, 2019 at 11:15:23PM +0100, Nicolas Cellier wrote:<br>
> I think that we should at least support the input/output of tonel packages<br>
> for inter-operability.<br>
> Since the git repositories are metadataless, we can't do much more without<br>
> a lot of work.<br>
> <br>
> Since tonel has no support for timestamps, it looses authorship (it is<br>
> replaced by committer-ship).<br>
> If we don't want to loose authorship, then we need to port whole history to<br>
> git with known initials <-> git(hub) account database.<br>
> This is currently working for single package with complex graph (to<br>
> filetree format, but could work for Tonel too).<br>
> If you want to commit several MC packages in same git repository, then it's<br>
> currently impossible to support complex history.<br>
> There is generally no information that enables inter-MC-package<br>
> synchronization (unless some sort of MCConfigurationMap is used, which at<br>
> least gives a few sync point in history...).<br>
> <br>
> If we want to perform essential operations like commit/pull/merge or access<br>
> essential information as history/revisions/diffs then we have to<br>
> - either reproduce the very hard work that began in Pharo: program a git<br>
> client inside the image,<br>
> - or loose inside image tools.<br>
> <br>
> Squeak MC tools are much more productive than Pharo MC tools:<br>
> - they scale well even for massive changes (i did check with auto generated<br>
> Smallapack interface)<br>
> - they support cherry-picking: you see and control what you commit<br>
> - they are quasi bugfree<br>
> - the magma backend provides a few additional features (revisions...)<br>
> Pharo team has produced huge effort for the github switch, but it does not<br>
> go without pain. Despite the importance of being visible on github, and<br>
> profit by state of the art web collaborating tools, i don't see Squeak able<br>
> to take this major turn in near future.<br>
> <br>
> If we want to have mix development with packages maintained both in a MC<br>
> repository and a git metadataless repository,<br>
> then we have the problem of finding a common ancestor.<br>
> I think that this could be doable with some conventions (like storing the<br>
> .last_known_mc_ancestor in a file)<br>
> Of course, it's re-introduction of metadata, but the minimal possible, and<br>
> leads to easy to resolve conflicts (that can be automated)...<br>
> <br>
> The last grief I have with Tonel is that it is not syntax agnostic.<br>
> Since we have a language where we can define compilerClass/parserClass,<br>
> that's unfortunate (The application i developed in the 90's did use such<br>
> important feature, it's not just theoretical)<br>
> It could have been language agnostic with very little effort (remember the<br>
> discussion on Pharo-dev, just using an arbitrary number of [[[   ]]] as<br>
> method body separators would suffice)<br>
> For most packages, that will not be a problem though.<br>
> <br>
> <br>
> Le jeu. 14 f??vr. 2019 ?? 15:17, Torsten Bergmann <<a href="mailto:astares@gmx.de" target="_blank" rel="noreferrer">astares@gmx.de</a>> a ??crit :<br>
> <br>
> > Hi,<br>
> ><br>
> > as some of you might already know "Tonel" is a file-per-class format for<br>
> > monticello repositories [1].<br>
> ><br>
> > In Pharo land many projects are already converted to it - as regular "file<br>
> > tree" solution faces issues<br>
> > with git handling due to very long file names / deep file hierarchy (often<br>
> > leading to trouble on Windows).<br>
> ><br>
> > Dales's Rowan (a new project/package manager for Smalltalk) supports<br>
> > FileTree and also Tonel<br>
> > repositories [2]. There is also a tool to convert from STORE (VisualWorks<br>
> > Source-Code Versioning System)<br>
> > to Tonel format [3].<br>
> ><br>
> > So I wonder about adoption of Tonel in Squeak land.<br>
> ><br>
> > Any status/comments?<br>
> ><br>
> > Thx<br>
> > T.<br>
> ><br>
> > [1] <a href="https://github.com/pharo-vcs/tonel" rel="noreferrer noreferrer" target="_blank">https://github.com/pharo-vcs/tonel</a><br>
> > [2] <a href="https://github.com/GemTalk/Rowan" rel="noreferrer noreferrer" target="_blank">https://github.com/GemTalk/Rowan</a><br>
> > [3]<br>
> > <a href="https://pharoweekly.wordpress.com/2019/01/20/ann-sett-store-export-to-tonel-tools-for-pharo6-1/" rel="noreferrer noreferrer" target="_blank">https://pharoweekly.wordpress.com/2019/01/20/ann-sett-store-export-to-tonel-tools-for-pharo6-1/</a><br>
> ><br>
> ><br>
> ><br>
> ><br>
<br>
> <br>
<br>
<br>
</blockquote></div></div></div>