Ok. So it is a missing feature. I will do individual diff'ing on versions
of the package that contains the method under concern instead. This is
after all not different from a git repo that uses eg a package.json file to
include external projects.
Thanks for enlightening me!
Siemen
On Thu, Mar 30, 2017 at 4:57 PM, Thierry Goubier <thierry.goub...@gmail.com>
wrote:
>
>
> 2017-03-30 16:42 GMT+02:00 Ben Coman <b...@openinworld.com>:
>
>> On Thu, Mar 30, 2017 at 2:58 PM, Siemen Baader <siemenbaa...@gmail.com>
>> wrote:
>> > Below is a fileout of 'ConfigurationOfPharoJS'. I download new releases
>> of
>> > PharoJS as they become available. Recently I found a regression - a
>> method
>> > 'PjApplication class >> playgroundWithoutLaunch' did not work any more.
>> What
>> > I wanted to do was to revert the whole project to an earlier version
>> until
>> > the method worked again - then look for the code that has been changed
>> > between releases and find the bug.
>> >
>> > In practice, even the earliest version (version 1.0 - method
>> #version10) did
>> > have the bug and I could not roll back the project to earlier release
>> states
>> > because there is no metadate for them. But I'd still like to learn how
>> to do
>> > it, so let's just say I want to compare version 1.2 and 1.3:
>> >
>> > version12: spec
>> > <version: '1.2' imports: #('0.1-baseline' )>
>> >
>> > version13: spec
>> > <version: '1.3' imports: #('0.2-baseline' )>
>> >
>> >
>> > I hope this makes sense. Thanks for helping me understand!
>>
>> You can only directly diff the Configurations themselves.
>> I fairly sure you can't auto-diff the packages loaded by each
>> configuration.
>> This is a missing feature. It would be nice to have something like
>> the merge-diff,
>> but there are probably other priorities. Maybe the new git workflow
>> will open some possibilities??
>>
>
> If you have a project-oriented way of committing to git (you commit both
> the configuration and all the packages in one commit), then diffing via git
> would work.
>
> Current status on that feature is:
>
> - BaselineOf and all related packages save in one commit can be done with
> GitFileTree. I added an API for that and made a few experiments by
> organising and saving projects via the Metacello registry (with GUI
> support). I rolled back that extension in AltBrowser and I will reimplement
> it soon in a different, better way.
>
> - Iceberg ?
>
> - ConfigurationOf ? The approach of storing a configurationOf inside a
> meta repository makes implementing that harder.
>
> Now, I think the tools would probably be able to get that to work over
> Monticello with few changes, but they are a tad complex to implement, as in
> loading two different configurationsOf and resolving related packages
> (without loading them), and then changing the diff viewer to project all
> differences between all classes of the two groups of packages. One thing to
> remember is that complete packages, in multiple versions, can be loaded
> simultaneously as Monticello models without disrupting the code currently
> loaded and active in the image, as when you "browse" a Monticello package
> on disk.
>
> Thierry
>
>
>>
>> cheers -ben
>>
>>
>
