updateDevelopment
Locked
 
|
hi Dale,
I am a bit lost with the method MetacelloBrowser>>updateDevelopment. I do not fully understand what it does. Does it solely check the repository for newer package version, and loads them if the user agrees upon? It does not save the packages that are modified right? This is the job of "Checkpoint Dev" This checkpoint dev uses MBSaveModifiedPackagesCommand. Does it make sense to move the method updateDevelopment into a new command, and make MBSaveModifiedPackagesCommand>>execute use this command to take care of the merge? By the way, why not rename "Checkpoint Dev" into "Save" or "Commit". Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
By the way, two methods turned yellow: #testIsDirty and #testPrintOn. The second one is not critical. But the first one says that tests are not completely isolated.
I will check into this. Alexandre On 9 Mar 2011, at 09:22, Alexandre Bergel wrote: > hi Dale, > > I am a bit lost with the method MetacelloBrowser>>updateDevelopment. I do not fully understand what it does. Does it solely check the repository for newer package version, and loads them if the user agrees upon? It does not save the packages that are modified right? This is the job of "Checkpoint Dev" > > This checkpoint dev uses MBSaveModifiedPackagesCommand. Does it make sense to move the method updateDevelopment into a new command, and make MBSaveModifiedPackagesCommand>>execute use this command to take care of the merge? > > By the way, why not rename "Checkpoint Dev" into "Save" or "Commit". > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
On 03/09/2011 04:24 AM, Alexandre Bergel wrote:
> By the way, two methods turned yellow: #testIsDirty and #testPrintOn. The second one is not critical. But the first one says that tests are not completely isolated. > I will check into this. > > Alexandre Yes I noticed this ... in GemStone the tests were yellow out of the box so I changed them so that they were green in Gemstone and of course they are yellow in Pharo ... it looks like we are depending upon some differences in the implementation between Pharo and GemStone when it comes to newly created packages ... A better test would be to test that the state of isDirty matches the state of the package ... Dale |
|
|
In reply to this post by abergel
On 03/09/2011 04:22 AM, Alexandre Bergel wrote:
> hi Dale, > > I am a bit lost with the method MetacelloBrowser>>updateDevelopment. I do not fully understand what it does. Does it solely check the repository for newer package version, and loads them if the user agrees upon? It does not save the packages that are modified right? This is the job of "Checkpoint Dev" > > This checkpoint dev uses MBSaveModifiedPackagesCommand. Does it make sense to move the method updateDevelopment into a new command, and make MBSaveModifiedPackagesCommand>>execute use this command to take care of the merge? > > By the way, why not rename "Checkpoint Dev" into "Save" or "Commit". > > Cheers, > Alexandre Update dev... basically updates the configuration package and then loads the development version again picking up newer versions of the mcz files along the way ... before doing all of this it scans for modified packages that would be overloaded and prompts the developer for an opportunity to merge ... I named it 'checkpoint dev' because that was shorter than 'save modified dev packages and configuration":) I am inclined to have the button names match a process step: - load config - update - checkpoint - release I think a test button would fit right in ... 'Save' on a button in the window would be too ambiguous (in my opinion), since the target of the save isn't obvious and what is going to be saved also isn't obvious... Dale |
|
|
In reply to this post by abergel
On 03/09/2011 04:22 AM, Alexandre Bergel wrote:
> hi Dale, > > I am a bit lost with the method MetacelloBrowser>>updateDevelopment. I do not fully understand what it does. Does it solely check the repository for newer package version, and loads them if the user agrees upon? It does not save the packages that are modified right? This is the job of "Checkpoint Dev" > > This checkpoint dev uses MBSaveModifiedPackagesCommand. Does it make sense to move the method updateDevelopment into a new command, and make MBSaveModifiedPackagesCommand>>execute use this command to take care of the merge? > > By the way, why not rename "Checkpoint Dev" into "Save" or "Commit". > > Cheers, > Alexandre Alexandre, You changed MBCommand username and password to forward the configurationRoot message to the requestor (changing from target), but the OB requestors do not implement nor store the root, so using OB I get a MNU (where I didn't before) ... I would have completely removed the password and username from MetacelloBrowser, but it was still being used there in a couple of places and I figured that it was better to expend effort moving the commands that are left in MetacelloBrowser to a subclass of MBCommand than it was to temporarily patch MetacelloBrowser to forward to the configuration root ... Sooo, I'm changing it back to the way it was... Dale |
|
|
> Alexandre,
> > You changed MBCommand username and password to forward the configurationRoot message to the requestor (changing from target), but the OB requestors do not implement nor store the root, so using OB I get a MNU (where I didn't before) ... I would have completely removed the password and username from MetacelloBrowser, but it was still being used there in a couple of places and I figured that it was better to expend effort moving the commands that are left in MetacelloBrowser to a subclass of MBCommand than it was to temporarily patch MetacelloBrowser to forward to the configuration root ... > Sooo, I'm changing it back to the way it was... Write some test please. I just tried to fix some red tests this morning. No test complained about the OB situation. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
Alexandre,
I have started work on moving the update tracking from the browsers to the configuration root ... ultimately the configuration root will be an independent (persistent) data structure in a image that will tack image state ... the browsers will register for configuration root announcements ... Take a look at the tests that I have started building in MBConfigurationRootTests ... the test is using a dictionary-based repository (I think I said directory-based in an earlier email) created from a resource. the tests are validating the data structures based upon controlled configurations and packages that are loaded from the repositories...The two tests that were failing earlier have been absorbed into the MBConfigurationRootTests and I think the earlier problems can be traced to using uncontrolled configurations for the tests... The command tests should use a similar style of loading test packages and configurations, validating the expected state, then run the command and validate that the correct state changes have occurred .. then we can be totally independent of the GUI implementation ... when the announcements have been implemented the same tests should validate that the expected announcements were fired ... Dale On Mar 9, 2011, at 11:42 AM, Alexandre Bergel wrote: >> Alexandre, >> >> You changed MBCommand username and password to forward the configurationRoot message to the requestor (changing from target), but the OB requestors do not implement nor store the root, so using OB I get a MNU (where I didn't before) ... I would have completely removed the password and username from MetacelloBrowser, but it was still being used there in a couple of places and I figured that it was better to expend effort moving the commands that are left in MetacelloBrowser to a subclass of MBCommand than it was to temporarily patch MetacelloBrowser to forward to the configuration root ... > > >> Sooo, I'm changing it back to the way it was... > > Write some test please. I just tried to fix some red tests this morning. No test complained about the OB situation. > > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > |
|
|
Excellent!
I would like to write a test that: (i) create some packages, (ii) create a configuration by actioning the +Configuration that includes the packages. But I am not sure how to start. I like your resources. Alexandre On 10 Mar 2011, at 04:02, Dale Henrichs wrote: > Alexandre, > > I have started work on moving the update tracking from the browsers to the configuration root ... ultimately the configuration root will be an independent (persistent) data structure in a image that will tack image state ... the browsers will register for configuration root announcements ... > > Take a look at the tests that I have started building in MBConfigurationRootTests ... the test is using a dictionary-based repository (I think I said directory-based in an earlier email) created from a resource. the tests are validating the data structures based upon controlled configurations and packages that are loaded from the repositories...The two tests that were failing earlier have been absorbed into the MBConfigurationRootTests and I think the earlier problems can be traced to using uncontrolled configurations for the tests... > > The command tests should use a similar style of loading test packages and configurations, validating the expected state, then run the command and validate that the correct state changes have occurred .. then we can be totally independent of the GUI implementation ... when the announcements have been implemented the same tests should validate that the expected announcements were fired ... > > Dale > On Mar 9, 2011, at 11:42 AM, Alexandre Bergel wrote: > >>> Alexandre, >>> >>> You changed MBCommand username and password to forward the configurationRoot message to the requestor (changing from target), but the OB requestors do not implement nor store the root, so using OB I get a MNU (where I didn't before) ... I would have completely removed the password and username from MetacelloBrowser, but it was still being used there in a couple of places and I figured that it was better to expend effort moving the commands that are left in MetacelloBrowser to a subclass of MBCommand than it was to temporarily patch MetacelloBrowser to forward to the configuration root ... >> >> >>> Sooo, I'm changing it back to the way it was... >> >> Write some test please. I just tried to fix some red tests this morning. No test complained about the OB situation. >> >> Alexandre >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
Alexandre,
Take a look at MBDevelopmentCycleTests>>testAddConfigurationCmd ... it is using a resource from Metacello ...mainly because I had a bunch of packages and configs already made ... we could/should create our own so that we're not impacted by changes to the Metacello resources... Dale On Mar 10, 2011, at 6:55 PM, Alexandre Bergel wrote: > Excellent! > I would like to write a test that: (i) create some packages, (ii) create a configuration by actioning the +Configuration that includes the packages. But I am not sure how to start. I like your resources. > > Alexandre > > > On 10 Mar 2011, at 04:02, Dale Henrichs wrote: > >> Alexandre, >> >> I have started work on moving the update tracking from the browsers to the configuration root ... ultimately the configuration root will be an independent (persistent) data structure in a image that will tack image state ... the browsers will register for configuration root announcements ... >> >> Take a look at the tests that I have started building in MBConfigurationRootTests ... the test is using a dictionary-based repository (I think I said directory-based in an earlier email) created from a resource. the tests are validating the data structures based upon controlled configurations and packages that are loaded from the repositories...The two tests that were failing earlier have been absorbed into the MBConfigurationRootTests and I think the earlier problems can be traced to using uncontrolled configurations for the tests... >> >> The command tests should use a similar style of loading test packages and configurations, validating the expected state, then run the command and validate that the correct state changes have occurred .. then we can be totally independent of the GUI implementation ... when the announcements have been implemented the same tests should validate that the expected announcements were fired ... >> >> Dale >> On Mar 9, 2011, at 11:42 AM, Alexandre Bergel wrote: >> >>>> Alexandre, >>>> >>>> You changed MBCommand username and password to forward the configurationRoot message to the requestor (changing from target), but the OB requestors do not implement nor store the root, so using OB I get a MNU (where I didn't before) ... I would have completely removed the password and username from MetacelloBrowser, but it was still being used there in a couple of places and I figured that it was better to expend effort moving the commands that are left in MetacelloBrowser to a subclass of MBCommand than it was to temporarily patch MetacelloBrowser to forward to the configuration root ... >>> >>> >>>> Sooo, I'm changing it back to the way it was... >>> >>> Write some test please. I just tried to fix some red tests this morning. No test complained about the OB situation. >>> >>> Alexandre >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > |
|
|
Alexandre,
With my latest commit, the MetacelloBrowser (both OB and Morphic) variants share the MBConfigurationRoot instance and system level update events are now handled by the configuration root instead of the browsers ... the browsers subscribe to MetacelloBrowser announcements for determining when to update the lists ... the MBConfigurationConfiguration root is a persistent cache of the configuation state including current version, etc...which means if the shared instance gets out of synch all windows are out of synch ... see MBConfigurationRoot class>>reset which can be used to force the root to be rebuilt (close any open windows first) There are unit tests for the update/event handling ... I'd like to get rid of the command level refresh code and rely on update events from the system and the configuration root to generate display updates ... there are still some issues with updates (but a lot fewer now) mainly with the OB windows... Dale |
«
Return to Metacello
|
1 view|%1 views
| Free forum by Nabble | Edit this page |