Hi,

On Jul 24, 2013, at 5:25 PM, Johan Brichau <jo...@inceptive.be> wrote:

> Doru,
> 
> What do you understand with 'levels'? Is it referenced projects?

Yes. Nested projects, each being under development  :)

> Perhaps this is the difference I did not immediately extract from your 
> description. Re-reading it with this focus makes the difference clear I think.
> 
> My use of the toolbox is indeed to generate or update a version for a single 
> project where all 'nested' projects are referenced by project version. As I 
> understand it, the snapshot version is a 'flattened' version containing all 
> packages?

Yes.

My end goal would be to be able to create automatic transitive versioning of 
all nested configurations, but this requires some more work, and likely some 
extension at the level of Metacello. So, until this happens, we now have the 
option of snapshotting all packages.

The cool thing is that if you have something like:
ConfigurationOfMoose depends on ConfigurationOfGlamour

then in the list of snapshotted packages, you will also get the version of 
ConfigurationOfGlamour. Thus, essentially, you obtain the same thing as if you 
would load nested configurations.

The only problem is that because we lose configuration nesting information, 
Metacello is unable to resolve possible diamond conflicts. For example, suppose 
you have a project that depends on a certain version X of Glamour, but also 
would like to load the whole Moose that loads version Y of Glamour. If you use 
normal configurations, Metacello should be able to detect the conflict, but if 
you only have flattened versions, you will likely not detect the conflict so 
easily. In any case, I think this is acceptable at the moment.

Cheers,
Doru



> I think I get it now. thanks
> 
> Johan
> 
> On 24 Jul 2013, at 12:45, Tudor Girba <tu...@tudorgirba.com> wrote:
> 
>> Perhaps I missed something in the toolbox, but as far as I know you cannot 
>> create a version of a configuration that is composed of multiple 
>> sub-projects nested multiple levels deep.
>> 
>> Could you describe the way you are using the Metacello Toolbox?
>> 
>> Doru
>> 
>> 
>> On Wed, Jul 24, 2013 at 10:39 AM, Johan Brichau <jo...@inceptive.be> wrote:
>> Hi Doru, Stef,
>> 
>> May I ask what the difference is with the version generation and updating 
>> methods found in MetacelloToolbox ? I want to understand, because I am 
>> currently using these of MetacelloToolbox to do the things you describe.
>> 
>> Cheers!
>> Johan
>> 
>> On 24 Jul 2013, at 09:52, Stéphane Ducasse <stephane.duca...@inria.fr> wrote:
>> 
>>> 
>>> On Jul 24, 2013, at 9:11 AM, Tudor Girba <tu...@tudorgirba.com> wrote:
>>> 
>>>> Hi,
>>>> 
>>>> On Jul 24, 2013, at 8:48 AM, Stéphane Ducasse <stephane.duca...@inria.fr> 
>>>> wrote:
>>>> 
>>>>> 
>>>>> On Jul 23, 2013, at 11:51 PM, Dale K. Henrichs 
>>>>> <dale.henri...@gemtalksystems.com> wrote:
>>>>> 
>>>>>> Stef,
>>>>>> 
>>>>>> I haven't completely wrapped my brain around what SnapshotCello does so 
>>>>>> I don't have an informed opinion ... the fact that you found a need to 
>>>>>> invent SnapshotCello does speak volumes to the fact that there is a need 
>>>>>> that is going unmet:).
>>>>>> 
>>>>>> However, I don't like the fact that you end up sending a non-spec 
>>>>>> message to make this work (#populateSpec:with:). Tools like Versioner 
>>>>>> will not be able to rewrite a method like this correctly so it is a less 
>>>>>> than satisfactory workaround to the method literal limit.
>>>>> Indeed. May be in the future we could recreate a simple compliant spec 
>>>>> driven method by interpreting the
>>>>> existing configuration trees but this requires some work.
>>>> 
>>>> I do not understand this point. What do you mean by "interpreting the 
>>>> configuration trees"?
>>> 
>>> I mean going over the configurations with dependencies to recreate the tree 
>>> structure but with versions.
>>> May be this is not needed because for versions we do not need dependencies 
>>> so just group them per configurations.
>>> 
>>>> 
>>>> Doru
>>>> 
>>>>>> 
>>>>>> With that said it _is_ performing a useful function ...
>>>>>> 
>>>>>> I have recently come up with an approach to addressing the method 
>>>>>> literal limit from a slightly different angle and I would assume that 
>>>>>> SnapshotCello could be recast to use this "approved approach" when the 
>>>>>> new techinique becomes available. At that time it would make sense to 
>>>>>> roll the SnapshotCello funtionality into the MetacelloToolBox...
>>>>>> 
>>>>>> Dale
>>>>>> 
>>>>>> [1] 
>>>>>> http://forum.world.st/Loading-problem-in-Seaside-tp4699965p4700161.html
>>>>>> ----- Original Message -----
>>>>>> | From: "Stéphane Ducasse" <stephane.duca...@inria.fr>
>>>>>> | To: "Moose-related development" <moose-...@iam.unibe.ch>
>>>>>> | Cc: "Any question about pharo is welcome" 
>>>>>> <pharo-us...@lists.pharo.org>, "Pharo Development List"
>>>>>> | <pharo-dev@lists.pharo.org>
>>>>>> | Sent: Tuesday, July 23, 2013 2:17:50 PM
>>>>>> | Subject: [Moose-dev] Re: [ann] snapshotcello
>>>>>> |
>>>>>> | Nice to see SnapshotCello coming to live. May be it should be
>>>>>> | integrated to Metacello.
>>>>>> | Because everybody may need this cool feature.
>>>>>> |
>>>>>> | Stef
>>>>>> |
>>>>>> | On Jul 23, 2013, at 10:43 PM, Tudor Girba <tu...@tudorgirba.com>
>>>>>> | wrote:
>>>>>> |
>>>>>> | > Hi,
>>>>>> | >
>>>>>> | > Stef and I developed Snapshotcello, a little utility that enables
>>>>>> | > you to freeze a snapshot of a given configuration based on what is
>>>>>> | > already loaded in your current image.
>>>>>> | >
>>>>>> | > The idea is simple. You develop against the latest versions of all
>>>>>> | > packages, and commit your changes for each package. When you are
>>>>>> | > ready for a release, you assemble your image, and generate a
>>>>>> | > snapshot version that can be reloaded later.
>>>>>> | >
>>>>>> | > Here is an example of how it can work to take a snapshot of a
>>>>>> | > development version:
>>>>>> | > Snapshotcello new
>>>>>> | >     configurationClass: ConfigurationOfMoose;
>>>>>> | >     configurationVersion: #development;
>>>>>> | >     publishVersion: '4.8-snapshot'
>>>>>> | >
>>>>>> | > You can find more details here:
>>>>>> | > 
>>>>>> http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-ready
>>>>>> | >
>>>>>> | > You can get the code at:
>>>>>> | > Gofer new
>>>>>> | >     smalltalkhubUser: 'girba' project: 'Snapshotcello';
>>>>>> | >     package: 'ConfigurationOfSnapshotcello';
>>>>>> | >     load.
>>>>>> | > (Smalltalk globals at: #ConfigurationOfSnapshotcello)
>>>>>> | > loadDevelopment
>>>>>> | >
>>>>>> | > Cheers,
>>>>>> | > Doru
>>>>>> | >
>>>>>> | > --
>>>>>> | > www.tudorgirba.com
>>>>>> | >
>>>>>> | > "Every successful trip needs a suitable vehicle."
>>>>>> | >
>>>>>> | >
>>>>>> | >
>>>>>> | >
>>>>>> | >
>>>>>> | > _______________________________________________
>>>>>> | > Moose-dev mailing list
>>>>>> | > moose-...@iam.unibe.ch
>>>>>> | > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>> |
>>>>>> |
>>>>>> | _______________________________________________
>>>>>> | Moose-dev mailing list
>>>>>> | moose-...@iam.unibe.ch
>>>>>> | https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>> |
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> moose-...@iam.unibe.ch
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>> 
>>>> --
>>>> www.tudorgirba.com
>>>> 
>>>> "From an abstract enough point of view, any two things are similar."
>>> 
>>> 
>> 
>> 
>> 
>> 
>> -- 
>> www.tudorgirba.com
>> 
>> "Every thing has its own flow"
> 
> 

--
www.tudorgirba.com

"Every now and then stop and ask yourself if the war you're fighting is the 
right one."




Reply via email to