> One of the thing that can be done is to temporarily copy all the versions
> concerned into a Git-based repository with Iceberg or GitFileTree, and then
> sees if git can provides a better diff, or even a git blame ability
Great tip, thanks, Thierry!
-- Siemen
> . I've done that multiple times... copy multiple versions in a repo, study
> the diff, and then just throw it away.
>
> Thierry
>
>>
>> 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
>
