Hi, I'm trying to load a package from a Tonel repository[1] that was created using SETT[2]. The structure seems fine, but when I try to load a package, I'm getting the message saying that there is no version for the package in the current commit (which seems wrong at least to the naked eye). Eg. Any idea of how to fix it? Regards! Esteban A. Maringolo |
Hi Esteban,
It seems like a bug in Iceberg. If you click on debug, you’ll see that although you’ve said the project is in tonel format, it’s trying to use a Filetree reader This is due to some missing metadata in the commit (iceberg is relying on commit information there and not working copy information). There is however a simple workaround. If you click in the commit button you’ll see that Iceberg tries to create and commit the missing files: If you commit those files, then you’ll be able to load your packages. Guille
|
I’ve created an issue:
https://github.com/pharo-vcs/iceberg/issues/1251
|
Hi Guillermo, Your workaround effectively solved my issue. About the tonel format, in the .properties file at the sources directory there was such setting: https://github.com/eMaringolo/rbac/blob/9279f22ef5fd1c4149090b5b39a6afa143a6519c/sources/properties.st But the .project file was missing at the root of the repository. So maybe it is a mix of both conditions. In any case, I'm glad the workaround works, and that it helped spotting a bug. Thank you! Esteban A. Maringolo On Tue, Jun 18, 2019 at 4:35 AM Guillermo Polito <[hidden email]> wrote:
|
SETT was create based on our understanding (GemTalk Systems) of what the tonel disk format was _supposed_ to be and I think that Pharo has departed from somewhat from what was understood to be the format. I've had similar problems trying to use filetree repositories with Iceberg that have been readable by the old Monticello/Filetree readers for years [1] ... and are readable when loaded through the Monticello Browser, but not readable when using Iceberg ... One of these days, there needs to be agreement as to what the actual disk format of tonel and filetree repositories is going to be/has been and then stick to them, otherwise these problems are going to continue to plague us. Dale [1] https://github.com/pharo-vcs/iceberg/issues/1239 On 6/18/19 6:40 AM, Esteban Maringolo
wrote:
|
Dale, Besides the issue affecting this particular case, I think that the Tonel "format" should support and honor "metadata" at the class/package/method level. E.g. the SETT exporter creates the #vw_namespace for classes, other dialects may need to specify other information that would be useful that when written back by Pharo are honored as well. E.g. You export a package from VW that has the class "Foo" in the "FooNamespace" namespace, so the Tonel class type definition will be defined with "Foo" as name and the #vw_namespace set to be "FooNamespace", if you lad this into Pharo everything will compile because the #vw_namespace will be ignored, but once you commit back the #vw_namespace property will be lost. I can think in other cases like Dolphin's class GUID or VAST Application/Subapplication mapping to a package or public/private to methods, etc. Tonel files don't have exactly the best format, but it seems to be the one that has the most widespread adoption in file based SCM, and maybe we (as a Smalltalk community) could make another attempt of having a common format to interchange code between dialects without much effort from the "main trunk" (Pharo). Regards, Esteban A. Maringolo On Tue, Jun 18, 2019 at 2:32 PM Dale Henrichs <[hidden email]> wrote:
|
Free forum by Nabble | Edit this page |