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.goubier@gmail.com> wrote:
2017-03-30 16:42 GMT+02:00 Ben Coman <btc@openinworld.com>:
On Thu, Mar 30, 2017 at 2:58 PM, Siemen Baader <siemenbaader@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