diff'ing with metacello

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

diff'ing with metacello

Siemen Baader
Hi all,

is there a tool to diff two Metacello versions with different baselines? I tried MetacelloBrowser (http://www.squeaksource.com/@6xz1bzmNF75EduBA/vZ263dVA) but it does not install on Pharo 5.0.

I need it to see what has changed when I install a new release of PharoJS and to bisect in search for regressions.

thanks,
Siemen
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: diff'ing with metacello

Ben Coman
Do you mean the difference between two "ConfigurationXXX....mcz" files?
As a workaround, perhaps load one and then from Monticello,
"start" to merge the other from Monticello and you will see a diff between them.

cheers -ben

On Tue, Mar 28, 2017 at 7:06 PM, Siemen Baader <[hidden email]> wrote:

> Hi all,
>
> is there a tool to diff two Metacello versions with different baselines? I
> tried MetacelloBrowser
> (http://www.squeaksource.com/@6xz1bzmNF75EduBA/vZ263dVA) but it does not
> install on Pharo 5.0.
>
> I need it to see what has changed when I install a new release of PharoJS
> and to bisect in search for regressions.
>
> thanks,
> Siemen

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: diff'ing with metacello

Siemen Baader


Sent from my iPhone

On 28/03/2017, at 13.52, Ben Coman <[hidden email]> wrote:

> Do you mean the difference between two "ConfigurationXXX....mcz" files?

I didn't know there were 'ConfigurationOfX.mcz' files. What do they contain?

What I want to see is what code has changed between two releases. In Git I would do it with a diff of the two releases' checksums. In other words, I want to see for releases described with metacello what the
Monticello browser can show us for versions of packages. Does this make sense? It seems like a very common use case to me, people must be doing it all the time, or...?

cheers,
Siemen


> As a workaround, perhaps load one and then from Monticello,
> "start" to merge the other from Monticello and you will see a diff between them.
>
> cheers -ben
>
> On Tue, Mar 28, 2017 at 7:06 PM, Siemen Baader <[hidden email]> wrote:
>> Hi all,
>>
>> is there a tool to diff two Metacello versions with different baselines? I
>> tried MetacelloBrowser
>> (http://www.squeaksource.com/@6xz1bzmNF75EduBA/vZ263dVA) but it does not
>> install on Pharo 5.0.
>>
>> I need it to see what has changed when I install a new release of PharoJS
>> and to bisect in search for regressions.
>>
>> thanks,
>> Siemen
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: diff'ing with metacello

Ben Coman
Can you provide a concrete case of two versions you want to compare?
cheers -ben

On Tue, Mar 28, 2017 at 8:51 PM, Siemen Baader <[hidden email]> wrote:

>
>
> Sent from my iPhone
>
> On 28/03/2017, at 13.52, Ben Coman <[hidden email]> wrote:
>
>> Do you mean the difference between two "ConfigurationXXX....mcz" files?
>
> I didn't know there were 'ConfigurationOfX.mcz' files. What do they contain?
>
> What I want to see is what code has changed between two releases. In Git I would do it with a diff of the two releases' checksums. In other words, I want to see for releases described with metacello what the
> Monticello browser can show us for versions of packages. Does this make sense? It seems like a very common use case to me, people must be doing it all the time, or...?
>
> cheers,
> Siemen
>
>
>> As a workaround, perhaps load one and then from Monticello,
>> "start" to merge the other from Monticello and you will see a diff between them.
>>
>> cheers -ben
>>
>> On Tue, Mar 28, 2017 at 7:06 PM, Siemen Baader <[hidden email]> wrote:
>>> Hi all,
>>>
>>> is there a tool to diff two Metacello versions with different baselines? I
>>> tried MetacelloBrowser
>>> (http://www.squeaksource.com/@6xz1bzmNF75EduBA/vZ263dVA) but it does not
>>> install on Pharo 5.0.
>>>
>>> I need it to see what has changed when I install a new release of PharoJS
>>> and to bisect in search for regressions.
>>>
>>> thanks,
>>> Siemen
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: diff'ing with metacello

Siemen Baader


Sent from my iPhone

On 28/03/2017, at 14.56, Ben Coman <[hidden email]> wrote:

> Can you provide a concrete case of two versions you want to compare?
> cheers -ben
>
Sure! I'm away from the computer but will post one ASAP!

> On Tue, Mar 28, 2017 at 8:51 PM, Siemen Baader <[hidden email]> wrote:
>>
>>
>> Sent from my iPhone
>>
>> On 28/03/2017, at 13.52, Ben Coman <[hidden email]> wrote:
>>
>>> Do you mean the difference between two "ConfigurationXXX....mcz" files?
>>
>> I didn't know there were 'ConfigurationOfX.mcz' files. What do they contain?
>>
>> What I want to see is what code has changed between two releases. In Git I would do it with a diff of the two releases' checksums. In other words, I want to see for releases described with metacello what the
>> Monticello browser can show us for versions of packages. Does this make sense? It seems like a very common use case to me, people must be doing it all the time, or...?
>>
>> cheers,
>> Siemen
>>
>>
>>> As a workaround, perhaps load one and then from Monticello,
>>> "start" to merge the other from Monticello and you will see a diff between them.
>>>
>>> cheers -ben
>>>
>>> On Tue, Mar 28, 2017 at 7:06 PM, Siemen Baader <[hidden email]> wrote:
>>>> Hi all,
>>>>
>>>> is there a tool to diff two Metacello versions with different baselines? I
>>>> tried MetacelloBrowser
>>>> (http://www.squeaksource.com/@6xz1bzmNF75EduBA/vZ263dVA) but it does not
>>>> install on Pharo 5.0.
>>>>
>>>> I need it to see what has changed when I install a new release of PharoJS
>>>> and to bisect in search for regressions.
>>>>
>>>> thanks,
>>>> Siemen
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: diff'ing with metacello

Siemen Baader
In reply to this post by Ben Coman
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!

-- Siemen

Fileout:
------------

'From Pharo5.0 of 16 April 2015 [Latest update: #50765] on 30 March 2017 at 8:41:59.866839 am'!
Object subclass: #ConfigurationOfPharoJS
instanceVariableNames: 'project'
classVariableNames: 'LastVersionLoad'
poolDictionaries: ''
category: 'ConfigurationOfPharoJS'!

!ConfigurationOfPharoJS methodsFor: 'symbolic versions' stamp: 'NouryBouraqadi 3/9/2017 17:03'!
development: spec
<symbolicVersion: #'development'>

spec for: #'common' version: '0.2-baseline'.
! !

!ConfigurationOfPharoJS methodsFor: 'symbolic versions' stamp: 'NouryBouraqadi 3/9/2017 17:03'!
stable: spec
<symbolicVersion: #'stable'>

spec for: #'common' version: '1.3'.
! !


!ConfigurationOfPharoJS methodsFor: 'accessing' stamp: 'NouryBouraqadi 12/6/2016 10:27'!
customProjectAttributes
    "Edit to return a collection of any custom attributes e.g. for conditional loading: Array with: #'Condition1' with: #'Condition2.

    ^ #()! !

!ConfigurationOfPharoJS methodsFor: 'accessing' stamp: 'NouryBouraqadi 12/6/2016 10:27'!
project 
    ^ project 
        ifNil: [ 
            "Bootstrap Metacello if it is not already loaded"
            self class ensureMetacello.
            project := MetacelloMCProject new projectAttributes: self customProjectAttributes. "Create the Metacello project"
            (Smalltalk at: #'MetacelloVersionConstructor') on: self project: project. "Construct the project"
            project loadType: #'linear'. "change to #atomic if desired"
            project ]! !


!ConfigurationOfPharoJS methodsFor: 'versions' stamp: 'NouryBouraqadi 3/9/2017 17:03'!
version13: spec
<version: '1.3' imports: #('0.2-baseline' )>

spec for: #'common' do: [
spec blessing: #'stable'.
spec description: 'version 1.3'.
spec author: 'NouryBouraqadi'.
spec timestamp: '3/9/2017 17:03'.
spec 
project: 'ReusableBricks' with: '1.2';
project: 'WebBrowser' with: '0.2.0';
project: 'ZincHTTPComponents' with: '2.8.3'.
spec 
package: 'PharoJsApp' with: 'PharoJsApp-DaveMason.27';
package: 'PharoJsBridge' with: 'PharoJsBridge-DaveMason.114';
package: #PharoJsCoreLibraries with: 'PharoJsCoreLibraries-NouryBouraqadi.85';
package: #PharoJsCoreLibrariesTest with: 'PharoJsCoreLibrariesTest-NouryBouraqadi.5';
package: 'PharoJsExamples' with: 'PharoJsExamples-NouryBouraqadi.24';
package: #PharoJsExporter with: 'PharoJsExporter-DaveMason.67';
package: 'PharoJsTestFramework' with: 'PharoJsTestFramework-NouryBouraqadi.43';
package: #PharoJsTiming with: 'PharoJsTiming-DaveMason.20';
package: 'PharoJsTools' with: 'PharoJsTools-DaveMason.33';
package: 'PharoJsTranspiler' with: 'PharoJsTranspiler-DaveMason.251';
package: #PharoJsTranspilerOptimization with: 'PharoJsTranspilerOptimization-DaveMason.36'. ].
! !

!ConfigurationOfPharoJS methodsFor: 'versions' stamp: 'NouryBouraqadi 2/18/2017 20:29'!
version12: spec
<version: '1.2' imports: #('0.1-baseline' )>

spec for: #'common' do: [
spec blessing: #'stable'.
spec description: 'version 1.2'.
spec author: 'NouryBouraqadi'.
spec timestamp: '2/18/2017 20:29'.
spec 
project: 'ReusableBricks' with: '1.2';
project: 'WebBrowser' with: '0.2.0';
project: 'ZincHTTPComponents' with: '2.8.3'.
spec 
package: 'PharoJsApp' with: 'PharoJsApp-NouryBouraqadi.25';
package: 'PharoJsBridge' with: 'PharoJsBridge-DaveMason.111';
package: #PharoJsCoreLibraries with: 'PharoJsCoreLibraries-DaveMason.79';
package: 'PharoJsExamples' with: 'PharoJsExamples-NouryBouraqadi.22';
package: #PharoJsExporter with: 'PharoJsExporter-DaveMason.65';
package: 'PharoJsTestFramework' with: 'PharoJsTestFramework-NouryBouraqadi.38';
package: #PharoJsTiming with: 'PharoJsTiming-DaveMason.20';
package: 'PharoJsTools' with: 'PharoJsTools-DaveMason.33';
package: 'PharoJsTranspiler' with: 'PharoJsTranspiler-DaveMason.248';
package: #PharoJsTranspilerOptimization with: 'PharoJsTranspilerOptimization-DaveMason.36'. ].
! !

!ConfigurationOfPharoJS methodsFor: 'versions' stamp: 'NouryBouraqadi 12/7/2016 13:19'!
version10: spec
<version: '1.0' imports: #('0.1-baseline' )>

spec for: #'common' do: [
spec blessing: #'stable'.
spec description: 'version 1.0'.
spec author: 'NouryBouraqadi'.
spec timestamp: '12/7/2016 13:19'.
spec 
project: 'ReusableBricks' with: '1.2';
project: 'WebBrowser' with: '0.2.0';
project: 'ZincHTTPComponents' with: '2.8.0'.
spec 
package: 'PharoJsApp' with: 'PharoJsApp-DaveMason.23';
package: 'PharoJsBridge' with: 'PharoJsBridge-NouryBouraqadi.86';
package: #PharoJsCoreLibraries with: 'PharoJsCoreLibraries-NouryBouraqadi.67';
package: 'PharoJsExamples' with: 'PharoJsExamples-NouryBouraqadi.17';
package: #PharoJsExporter with: 'PharoJsExporter-DaveMason.54';
package: 'PharoJsTestFramework' with: 'PharoJsTestFramework-NouryBouraqadi.35';
package: #PharoJsTiming with: 'PharoJsTiming-DaveMason.16';
package: 'PharoJsTools' with: 'PharoJsTools-DaveMason.22';
package: 'PharoJsTranspiler' with: 'PharoJsTranspiler-NouryBouraqadi.237';
package: #PharoJsTranspilerOptimization with: 'PharoJsTranspilerOptimization-DaveMason.35'. ].
! !

!ConfigurationOfPharoJS methodsFor: 'versions' stamp: 'NouryBouraqadi 2/6/2017 17:53'!
version11: spec
<version: '1.1' imports: #('0.1-baseline' )>

spec for: #'common' do: [
spec blessing: #'stable'.
spec description: 'version 1.1'.
spec author: 'NouryBouraqadi'.
spec timestamp: '2/6/2017 17:53'.
spec 
project: 'ReusableBricks' with: '1.2';
project: 'WebBrowser' with: '0.2.0';
project: 'ZincHTTPComponents' with: '2.8.2'.
spec 
package: 'PharoJsApp' with: 'PharoJsApp-NouryBouraqadi.25';
package: 'PharoJsBridge' with: 'PharoJsBridge-NouryBouraqadi.109';
package: #PharoJsCoreLibraries with: 'PharoJsCoreLibraries-NouryBouraqadi.77';
package: 'PharoJsExamples' with: 'PharoJsExamples-NouryBouraqadi.22';
package: #PharoJsExporter with: 'PharoJsExporter-nouryBouraqadi.64';
package: 'PharoJsTestFramework' with: 'PharoJsTestFramework-NouryBouraqadi.38';
package: #PharoJsTiming with: 'PharoJsTiming-DaveMason.20';
package: 'PharoJsTools' with: 'PharoJsTools-NouryBouraqadi.32';
package: 'PharoJsTranspiler' with: 'PharoJsTranspiler-NouryBouraqadi.246';
package: #PharoJsTranspilerOptimization with: 'PharoJsTranspilerOptimization-DaveMason.35'. ].
! !


!ConfigurationOfPharoJS methodsFor: 'baselines' stamp: 'NouryBouraqadi 12/6/2016 10:29'!
baseline01: spec
<version: '0.1-baseline'>

spec for: #'common' do: [
spec blessing: #'baseline'.
spec 
project: 'ReusableBricks' with: [
spec
className: #ConfigurationOfReusableBricks;
versionString: #'stable';
loads: #('Equals' );
project: 'WebBrowser' with: [
spec
className: #ConfigurationOfWebBrowser;
versionString: #'stable';
project: 'ZincHTTPComponents' with: [
spec
className: #ConfigurationOfZincHTTPComponents;
versionString: #'stable';
loads: #('Zinc-WebSocket-Core' );
spec 
package: 'PharoJsApp' with: [
spec requires: #('PharoJsTranspiler' ). ];
package: 'PharoJsBridge' with: [
spec requires: #(#PharoJsCoreLibraries #PharoJsExporter 'PharoJsApp' 'WebBrowser' 'ZincHTTPComponents' ). ];
package: #PharoJsCoreLibraries with: [
spec requires: #('PharoJsTranspiler' ). ];
package: 'PharoJsExamples' with: [
spec requires: #('PharoJsApp' 'PharoJsTranspiler' 'PharoJsTestFramework' ). ];
package: #PharoJsExporter with: [
spec requires: #('PharoJsTranspiler' 'PharoJsApp' ). ];
package: 'PharoJsTestFramework' with: [
spec requires: #(#PharoJsExporter 'PharoJsBridge' 'PharoJsApp' ). ];
package: #PharoJsTiming with: [
spec requires: #(#PharoJsTranspilerOptimization 'PharoJsBridge' ). ];
package: 'PharoJsTools' with: [
spec requires: #('PharoJsBridge' ). ];
package: 'PharoJsTranspiler' with: [
spec requires: #('ReusableBricks' ). ];
package: #PharoJsTranspilerOptimization with: [
spec requires: #('PharoJsTranspiler' ). ]. ].
! !

!ConfigurationOfPharoJS methodsFor: 'baselines' stamp: 'NouryBouraqadi 3/3/2017 12:36'!
baseline02: spec
<version: '0.2-baseline'>

spec for: #'common' do: [
spec blessing: #'baseline'.
spec 
project: 'ReusableBricks' with: [
spec
className: #ConfigurationOfReusableBricks;
versionString: #'stable';
loads: #('Equals' );
project: 'WebBrowser' with: [
spec
className: #ConfigurationOfWebBrowser;
versionString: #'stable';
project: 'ZincHTTPComponents' with: [
spec
className: #ConfigurationOfZincHTTPComponents;
versionString: #'stable';
loads: #('Zinc-WebSocket-Core' );
spec 
package: 'PharoJsApp' with: [
spec requires: #('PharoJsTranspiler' ). ];
package: 'PharoJsBridge' with: [
spec requires: #(#PharoJsCoreLibraries #PharoJsExporter 'PharoJsApp' 'WebBrowser' 'ZincHTTPComponents' ). ];
package: #PharoJsCoreLibraries with: [
spec requires: #('PharoJsTranspiler' ). ];
package: #PharoJsCoreLibrariesTest with: [
spec requires: #(#PharoJsCoreLibraries 'PharoJsBridge' ). ];
package: 'PharoJsExamples' with: [
spec requires: #('PharoJsApp' 'PharoJsTranspiler' 'PharoJsTestFramework' ). ];
package: #PharoJsExporter with: [
spec requires: #('PharoJsTranspiler' 'PharoJsApp' ). ];
package: 'PharoJsTestFramework' with: [
spec requires: #(#PharoJsExporter 'PharoJsBridge' 'PharoJsApp' ). ];
package: #PharoJsTiming with: [
spec requires: #(#PharoJsTranspilerOptimization 'PharoJsBridge' ). ];
package: 'PharoJsTools' with: [
spec requires: #('PharoJsBridge' ). ];
package: 'PharoJsTranspiler' with: [
spec requires: #('ReusableBricks' ). ];
package: #PharoJsTranspilerOptimization with: [
spec requires: #('PharoJsTranspiler' ). ]. ].
! !

"-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "!

ConfigurationOfPharoJS class
instanceVariableNames: ''!

!ConfigurationOfPharoJS class methodsFor: 'loading' stamp: 'NouryBouraqadi 12/6/2016 10:27'!
loadDevelopment
"Load the #development version defined for this platform. The #development version will change over time and is not expected to be stable."

"self loadDevelopment"

<apiDocumentation>
^(self project version: #development) load! !

!ConfigurationOfPharoJS class methodsFor: 'loading' stamp: 'NouryBouraqadi 12/6/2016 10:27'!
load
"Load the #stable version defined for this platform. The #stable version is the version that is recommended to be used on this platform."

"self load"

<apiDocumentation>
^(self project version: #stable) load! !

!ConfigurationOfPharoJS class methodsFor: 'loading' stamp: 'NouryBouraqadi 12/6/2016 10:27'!
loadBleedingEdge
"Load the latest versions of the mcz files defined for this project. It is not likely that the #bleedingEdge has been tested."

"self loadBleedingEdge"

<apiDocumentation>
^(self project version: #bleedingEdge) load! !


!ConfigurationOfPharoJS class methodsFor: 'private' stamp: 'NouryBouraqadi 12/6/2016 10:27'!
ensureMetacello

(self baseConfigurationClassIfAbsent: []) ensureMetacello! !

!ConfigurationOfPharoJS class methodsFor: 'private' stamp: 'NouryBouraqadi 12/6/2016 10:27'!
baseConfigurationClassIfAbsent: aBlock

^Smalltalk
at: #'ConfigurationOf'
ifAbsent: [ 
self ensureMetacelloBaseConfiguration.
Smalltalk at: #'ConfigurationOf' ifAbsent: aBlock ].! !

!ConfigurationOfPharoJS class methodsFor: 'private' stamp: 'NouryBouraqadi 12/6/2016 10:27'!
ensureMetacelloBaseConfiguration
  Smalltalk
    at: #'ConfigurationOf'
    ifAbsent: [ 
      | repository version |
      repository := MCHttpRepository
        user: ''
        password: ''.
      repository
        versionReaderForFileNamed: 'Metacello-Base-dkh.107'
        do: [ :reader | 
          version := reader version.
          version load.
          version workingCopy repositoryGroup addRepository: repository ] ]! !


!ConfigurationOfPharoJS class methodsFor: 'development support' stamp: 'NouryBouraqadi 12/6/2016 10:27'!
DevelopmentSupport

"See the methods in the 'development support' category on the class-side of MetacelloBaseConfiguration. Decide what development support methods you would like to use and copy them the the class-side of your configuration."
<apiDocumentation>! !

!ConfigurationOfPharoJS class methodsFor: 'development support' stamp: 'NouryBouraqadi 12/6/2016 10:27'!
validate
"Check the configuration for Errors, Critical Warnings, and Warnings (see class comment for MetacelloMCVersionValidator for more information). 
Errors identify specification issues that will result in unexpected behaviour when you load the configuration. 
Critical Warnings identify specification issues that may result in unexpected behavior when you load the configuration.
Warnings identify specification issues that are technically correct, but are worth take a look at."

"self validate"

<apiDocumentation>
self ensureMetacello.
^ ((Smalltalk at: #MetacelloToolBox) validateConfiguration: self debug: #() recurse: false) explore! !


!ConfigurationOfPharoJS class methodsFor: 'accessing' stamp: 'NouryBouraqadi 12/6/2016 10:27'!
project

^self new project! !


!ConfigurationOfPharoJS class methodsFor: 'metacello tool support' stamp: 'NouryBouraqadi 12/6/2016 10:27'!
isMetacelloConfig
"Answer true and the Metacello tools will operate on you"
^true! !


On Tue, Mar 28, 2017 at 2:56 PM, Ben Coman <[hidden email]> wrote:
Can you provide a concrete case of two versions you want to compare?
cheers -ben

On Tue, Mar 28, 2017 at 8:51 PM, Siemen Baader <[hidden email]> wrote:
>
>
> Sent from my iPhone
>
> On 28/03/2017, at 13.52, Ben Coman <[hidden email]> wrote:
>
>> Do you mean the difference between two "ConfigurationXXX....mcz" files?
>
> I didn't know there were 'ConfigurationOfX.mcz' files. What do they contain?
>
> What I want to see is what code has changed between two releases. In Git I would do it with a diff of the two releases' checksums. In other words, I want to see for releases described with metacello what the
> Monticello browser can show us for versions of packages. Does this make sense? It seems like a very common use case to me, people must be doing it all the time, or...?
>
> cheers,
> Siemen
>
>
>> As a workaround, perhaps load one and then from Monticello,
>> "start" to merge the other from Monticello and you will see a diff between them.
>>
>> cheers -ben
>>
>> On Tue, Mar 28, 2017 at 7:06 PM, Siemen Baader <[hidden email]> wrote:
>>> Hi all,
>>>
>>> is there a tool to diff two Metacello versions with different baselines? I
>>> tried MetacelloBrowser
>>> (http://www.squeaksource.com/@6xz1bzmNF75EduBA/vZ263dVA) but it does not
>>> install on Pharo 5.0.
>>>
>>> I need it to see what has changed when I install a new release of PharoJS
>>> and to bisect in search for regressions.
>>>
>>> thanks,
>>> Siemen
>>
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: diff'ing with metacello

Ben Coman
On Thu, Mar 30, 2017 at 2:58 PM, Siemen Baader <[hidden email]> 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??

cheers -ben

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: diff'ing with metacello

Thierry Goubier


2017-03-30 16:42 GMT+02:00 Ben Coman <[hidden email]>:
On Thu, Mar 30, 2017 at 2:58 PM, Siemen Baader <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: diff'ing with metacello

Siemen Baader
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 <[hidden email]> wrote:


2017-03-30 16:42 GMT+02:00 Ben Coman <[hidden email]>:
On Thu, Mar 30, 2017 at 2:58 PM, Siemen Baader <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: diff'ing with metacello

Thierry Goubier


2017-03-31 8:16 GMT+02:00 Siemen Baader <[hidden email]>:
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 <[hidden email]> wrote:


2017-03-30 16:42 GMT+02:00 Ben Coman <[hidden email]>:
On Thu, Mar 30, 2017 at 2:58 PM, Siemen Baader <[hidden email]> 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




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: diff'ing with metacello

Siemen Baader

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 <[hidden email]> wrote:


2017-03-30 16:42 GMT+02:00 Ben Coman <[hidden email]>:
On Thu, Mar 30, 2017 at 2:58 PM, Siemen Baader <[hidden email]> 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




Loading...