2017-03-31 8:16 GMT+02:00 Siemen Baader <siemenbaa...@gmail.com>:
> 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.
>
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. 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
>>>
>>>
>>
>
