MetacelloBrowser
Locked
 
|
Alex,
Before you check in a new version of MetacelloBrowser you need to merge in any changes that I have made into your version of the configuration ... Apparently you are opening a new development version with each checkin, but since you don't commit the new development version I don't see it and I make changes to the "old development" version then when you come along with a change you commit your "new version" essentially ignoring any changes that I may have made ... yesterday I added a new baseline with two new packages and restructured the packages and after your commit I have been working to manually move the new structure components to the newer version ... I don't think it is a good idea to commit a new metacello version every time you commit a new version of the mcz package ... it is redundant and makes it much more difficult to merge structural changes to the config ... If instead you simply 'Update dev" before starting work (getting the latest code _and _ configuration) do your work and and then use 'Checkpoint dev' to save your work it will make doing merges of config structure much easier ... We've already added automatic merge detection to the update side and we need to add merge detection when saving ... Dale |
|
|
Sorry for this. I have a kind of tendency to forget checking the repository before saving.
But best would be an automatic mechanism for this. You once said there is something like this in Metacello? Where is it? Cheers, Alexandre On 6 Mar 2011, at 14:36, Dale Henrichs wrote: > Alex, > > Before you check in a new version of MetacelloBrowser you need to merge in any changes that I have made into your version of the configuration ... Apparently you are opening a new development version with each checkin, but since you don't commit the new development version I don't see it and I make changes to the "old development" version then when you come along with a change you commit your "new version" essentially ignoring any changes that I may have made ... yesterday I added a new baseline with two new packages and restructured the packages and after your commit I have been working to manually move the new structure components to the newer version ... > > I don't think it is a good idea to commit a new metacello version every time you commit a new version of the mcz package ... it is redundant and makes it much more difficult to merge structural changes to the config ... > > If instead you simply 'Update dev" before starting work (getting the latest code _and _ configuration) do your work and and then use 'Checkpoint dev' to save your work it will make doing merges of config structure much easier ... > > We've already added automatic merge detection to the update side and we need to add merge detection when saving ... > > Dale > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
On Mar 6, 2011, at 10:55 AM, Alexandre Bergel wrote: > Sorry for this. I have a kind of tendency to forget checking the repository before saving. > But best would be an automatic mechanism for this. You once said there is something like this in Metacello? Where is it? > The Upgrade Dev command checks for the intersection of modified packages and packages sheduled to be loaded and allows you to merge with the merge browser ... Dale |
|
|
In reply to this post by Alexandre Bergel-5
Alexandre,
Both 1.56 and 1.57 are missing the mcz versions that I had put into 1.55 ... we have to stop snapping off new metacello versions like this ... Please wait for mail from me before committing any more changes since I have to now manually bring forward my changes to 1.57 and merge with your changes .... When I have got 1.57 stabilized lets stop creating new Metacello versions on every commit ... Let's try to do development in a single version ... 1.57 and see how that goes ... Update Dev right before a commit to take the opportunity to merge and pick up the latest changes to the config followed by Checkpoint Dev to save modified packages and new version of the config .... this should work better .... there is still a window where we are both committing at the same time, but let's see how often that happens... Dale On Mar 6, 2011, at 10:55 AM, Alexandre Bergel wrote: > Sorry for this. I have a kind of tendency to forget checking the repository before saving. > But best would be an automatic mechanism for this. You once said there is something like this in Metacello? Where is it? > > Cheers, > Alexandre > > > On 6 Mar 2011, at 14:36, Dale Henrichs wrote: > >> Alex, >> >> Before you check in a new version of MetacelloBrowser you need to merge in any changes that I have made into your version of the configuration ... Apparently you are opening a new development version with each checkin, but since you don't commit the new development version I don't see it and I make changes to the "old development" version then when you come along with a change you commit your "new version" essentially ignoring any changes that I may have made ... yesterday I added a new baseline with two new packages and restructured the packages and after your commit I have been working to manually move the new structure components to the newer version ... >> >> I don't think it is a good idea to commit a new metacello version every time you commit a new version of the mcz package ... it is redundant and makes it much more difficult to merge structural changes to the config ... >> >> If instead you simply 'Update dev" before starting work (getting the latest code _and _ configuration) do your work and and then use 'Checkpoint dev' to save your work it will make doing merges of config structure much easier ... >> >> We've already added automatic merge detection to the update side and we need to add merge detection when saving ... >> >> Dale >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > |
|
|
I've committed the new version to the repository, so it's time to synchronize ... In the end it wasn't a lost change, just two new versions of mcz files and two new metacello versions.
I take it that I will just have to learn to live with the development version moving out from under me every time to you change an mcz file? Dale On Mar 6, 2011, at 11:19 AM, Dale Henrichs wrote: > Alexandre, > > Both 1.56 and 1.57 are missing the mcz versions that I had put into 1.55 ... we have to stop snapping off new metacello versions like this ... > > Please wait for mail from me before committing any more changes since I have to now manually bring forward my changes to 1.57 and merge with your changes .... > > When I have got 1.57 stabilized lets stop creating new Metacello versions on every commit ... > > Let's try to do development in a single version ... 1.57 and see how that goes ... Update Dev right before a commit to take the opportunity to merge and pick up the latest changes to the config followed by Checkpoint Dev to save modified packages and new version of the config .... this should work better .... there is still a window where we are both committing at the same time, but let's see how often that happens... > > Dale > > On Mar 6, 2011, at 10:55 AM, Alexandre Bergel wrote: > >> Sorry for this. I have a kind of tendency to forget checking the repository before saving. >> But best would be an automatic mechanism for this. You once said there is something like this in Metacello? Where is it? >> >> Cheers, >> Alexandre >> >> >> On 6 Mar 2011, at 14:36, Dale Henrichs wrote: >> >>> Alex, >>> >>> Before you check in a new version of MetacelloBrowser you need to merge in any changes that I have made into your version of the configuration ... Apparently you are opening a new development version with each checkin, but since you don't commit the new development version I don't see it and I make changes to the "old development" version then when you come along with a change you commit your "new version" essentially ignoring any changes that I may have made ... yesterday I added a new baseline with two new packages and restructured the packages and after your commit I have been working to manually move the new structure components to the newer version ... >>> >>> I don't think it is a good idea to commit a new metacello version every time you commit a new version of the mcz package ... it is redundant and makes it much more difficult to merge structural changes to the config ... >>> >>> If instead you simply 'Update dev" before starting work (getting the latest code _and _ configuration) do your work and and then use 'Checkpoint dev' to save your work it will make doing merges of config structure much easier ... >>> >>> We've already added automatic merge detection to the update side and we need to add merge detection when saving ... >>> >>> Dale >>> >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> > |
|
|
In reply to this post by Dale Henrichs
> Both 1.56 and 1.57 are missing the mcz versions that I had put into 1.55 ... we have to stop snapping off new metacello versions like this ...
How come. Before committing I checked the repository, and there was nothing new. I do not understand what the problem is. > Please wait for mail from me before committing any more changes since I have to now manually bring forward my changes to 1.57 and merge with your changes .... Ok. There is the scenario suggested by Stef that I would like to work on it. But I will let you know. > When I have got 1.57 stabilized lets stop creating new Metacello versions on every commit ... Ok, I will use "Upgrade Dev". But I do not see how reducing the amount of versions will solve the problem. > Let's try to do development in a single version ... 1.57 and see how that goes ... Update Dev right before a commit to take the opportunity to merge and pick up the latest changes to the config followed by Checkpoint Dev to save modified packages and new version of the config .... this should work better .... there is still a window where we are both committing at the same time, but let's see how often that happens... I like the idea of having many versions with small increments. Having less versions with a bigger increment for each is risky to me, beside the fact that is reduce traceability. But ok, I will not create new version before consulting you. Alexandre > > On Mar 6, 2011, at 10:55 AM, Alexandre Bergel wrote: > >> Sorry for this. I have a kind of tendency to forget checking the repository before saving. >> But best would be an automatic mechanism for this. You once said there is something like this in Metacello? Where is it? >> >> Cheers, >> Alexandre >> >> >> On 6 Mar 2011, at 14:36, Dale Henrichs wrote: >> >>> Alex, >>> >>> Before you check in a new version of MetacelloBrowser you need to merge in any changes that I have made into your version of the configuration ... Apparently you are opening a new development version with each checkin, but since you don't commit the new development version I don't see it and I make changes to the "old development" version then when you come along with a change you commit your "new version" essentially ignoring any changes that I may have made ... yesterday I added a new baseline with two new packages and restructured the packages and after your commit I have been working to manually move the new structure components to the newer version ... >>> >>> I don't think it is a good idea to commit a new metacello version every time you commit a new version of the mcz package ... it is redundant and makes it much more difficult to merge structural changes to the config ... >>> >>> If instead you simply 'Update dev" before starting work (getting the latest code _and _ configuration) do your work and and then use 'Checkpoint dev' to save your work it will make doing merges of config structure much easier ... >>> >>> We've already added automatic merge detection to the update side and we need to add merge detection when saving ... >>> >>> Dale >>> >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
In reply to this post by Dale Henrichs
> I take it that I will just have to learn to live with the development version moving out from under me every time to you change an mcz file?
No, it is okay. I am flexible :-) I will not create a new version before consulting you. I will use the "update dev" button :-) Alexandre > > On Mar 6, 2011, at 11:19 AM, Dale Henrichs wrote: > >> Alexandre, >> >> Both 1.56 and 1.57 are missing the mcz versions that I had put into 1.55 ... we have to stop snapping off new metacello versions like this ... >> >> Please wait for mail from me before committing any more changes since I have to now manually bring forward my changes to 1.57 and merge with your changes .... >> >> When I have got 1.57 stabilized lets stop creating new Metacello versions on every commit ... >> >> Let's try to do development in a single version ... 1.57 and see how that goes ... Update Dev right before a commit to take the opportunity to merge and pick up the latest changes to the config followed by Checkpoint Dev to save modified packages and new version of the config .... this should work better .... there is still a window where we are both committing at the same time, but let's see how often that happens... >> >> Dale >> >> On Mar 6, 2011, at 10:55 AM, Alexandre Bergel wrote: >> >>> Sorry for this. I have a kind of tendency to forget checking the repository before saving. >>> But best would be an automatic mechanism for this. You once said there is something like this in Metacello? Where is it? >>> >>> Cheers, >>> Alexandre >>> >>> >>> On 6 Mar 2011, at 14:36, Dale Henrichs wrote: >>> >>>> Alex, >>>> >>>> Before you check in a new version of MetacelloBrowser you need to merge in any changes that I have made into your version of the configuration ... Apparently you are opening a new development version with each checkin, but since you don't commit the new development version I don't see it and I make changes to the "old development" version then when you come along with a change you commit your "new version" essentially ignoring any changes that I may have made ... yesterday I added a new baseline with two new packages and restructured the packages and after your commit I have been working to manually move the new structure components to the newer version ... >>>> >>>> I don't think it is a good idea to commit a new metacello version every time you commit a new version of the mcz package ... it is redundant and makes it much more difficult to merge structural changes to the config ... >>>> >>>> If instead you simply 'Update dev" before starting work (getting the latest code _and _ configuration) do your work and and then use 'Checkpoint dev' to save your work it will make doing merges of config structure much easier ... >>>> >>>> We've already added automatic merge detection to the update side and we need to add merge detection when saving ... >>>> >>>> Dale >>>> >>>> >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
In reply to this post by Alexandre Bergel-5
On Mar 6, 2011, at 11:40 AM, Alexandre Bergel wrote: Both 1.56 and 1.57 are missing the mcz versions that I had put into 1.55 ... we have to stop snapping off new metacello versions like this ... How come. Before committing I checked the repository, and there was nothing new. I do not understand what the problem is. I was momentarily confused by the two versions and thought the problem was caused by one thing when it was another. Please wait for mail from me before committing any more changes since I have to now manually bring forward my changes to 1.57 and merge with your changes .... Ok. There is the scenario suggested by Stef that I would like to work on it. But I will let you know. The configuration is ready now ... When I have got 1.57 stabilized lets stop creating new Metacello versions on every commit ... Ok, I will use "Upgrade Dev". But I do not see how reducing the amount of versions will solve the problem. The problem is that we are trying to work on one project while using two different development styles ... it is hard enough to keep track of the mcz files that need to be merged without having to worry about merging configuration versions as well ... Let's try to do development in a single version ... 1.57 and see how that goes ... Update Dev right before a commit to take the opportunity to merge and pick up the latest changes to the config followed by Checkpoint Dev to save modified packages and new version of the config .... this should work better .... there is still a window where we are both committing at the same time, but let's see how often that happens... I like the idea of having many versions with small increments. Having less versions with a bigger increment for each is risky to me, beside the fact that is reduce traceability. But ok, I will not create new version before consulting you. I like the idea of many versions with small increments, but I don't agree that incrementing the Metacello version number for each mcz file commit servers any purpose... we have full traceability without having to increment the Metacello version number ... we have the unique mcz file versions and we have a version of the configuration (the mcz version) that records an update to the metacello version ... if I want to view the history of changes I can see that by looking at the mcz history for the configuration and if I do a diff between two mcz versions of the configuration I can see exactly what packages or structural modifications were made ... when a new version is added it is like renaming a class in Monticello all historical information is lost and it is much more difficult to understand what is going on ... Don't get me wrong I like many small versions and I like traceability, I just don't believe that incrementing the metacallo version number enhances traceability... Dale |
|
|
> Don't get me wrong I like many small versions and I like traceability, I just don't believe that incrementing the metacallo version number enhances traceability...
Just to be sure. Consider the scenario using my development style: Version 1.0 is made of A-ab.1.mcz, B-ab.10.mcz and C-dkh.5.mcz Version 1.1 is made of A-ab.1.mcz, B-ab.11.mcz and C-dkh.5.mcz Version 1.2 is made of A-ab.2.mcz, B-ab.11.mcz and C-dkh.6.mcz There is a new version for each version. Now, if we said we do not need to have Version 1.1, in order to reduce the numbering. If Version 1.0 have all test green, and Version 1.2 some red ones. Without considering Version 1.1, it is more difficult to identify what has caused the red tests. We can manually check A-ab.2.mcz, B-ab.11.mcz and C-dkh.6.mcz. But Version 1.1 says that A-ab.2.mcz is made to work with C-dkh.6.mcz. This is something very important that only an intermediate version can say. But if I am not missing something in the picture, then I feel having fewer explicit versions increases confusion if something got wrong. As I said, I am ready to accommodate my coding style with larger increment. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
Okay,
There is also a new version of the configuration mcz file for each mcz file version, so to include _all_ of the available information, you must also show the config mcz version: Version 1.0 is made of A-ab.1.mcz, B-ab.10.mcz and C-dkh.5.mcz <-- Config-ab.256.mcz Version 1.1 is made of A-ab.1.mcz, B-ab.11.mcz and C-dkh.5.mcz <-- Config-ab.257.mcz Version 1.2 is made of A-ab.2.mcz, B-ab.11.mcz and C-dkh.6.mcz <-- Config-ab.258.mcz Given that we have the config file versions we _can_ use the same Metacello version number (1.0) without the loss of information: Version 1.0 is made of A-ab.1.mcz, B-ab.10.mcz and C-dkh.5.mcz <-- Config-ab.256.mcz Version 1.0 is made of A-ab.1.mcz, B-ab.11.mcz and C-dkh.5.mcz <-- Config-ab.257.mcz Version 1.0 is made of A-ab.2.mcz, B-ab.11.mcz and C-dkh.6.mcz <-- Config-ab.258.mcz The information content is the same but just expressed differently: In Config-ab.256.mcz the tests were all green and in Config-ab.258.mcz there were some red tests. Using the existing mcz package comparison tools we can compare the specifications from Config-ab.258.mcz to Config-ab.256 or Config-ab.257.mcz see that B-ab.11.mcz was updated between Config-ab.256.mcz and Config-ab.257.mcz and that other two packages were changed between Config-ab.257.mcz and Config-ab.258.mcz ... we haven't lost any information ... Incrementing the Metacello version number in addition to saving a version of the config is redundant and doesn't actually add any additional information ... in my opinion it adds an unnecessary (and confusing) layer of indirection. In my mind, the Metacello version numbers are aimed at the users of the project, not the developers of the project. In my mind, developers open version 1.1 for development and that is the target release version that this round of development is targeted for. When 1.1 is completed (with full development history recorded in the configuration mcz file) the version is released to end users and they go about their business. By limiting the rate at which Metacello versions are created the users see a natural progression of version numbers for the releases: 1.0 ... 1.2 ... 1.3 ... The file name of the mcz file for the configuration is the moral equivalent of the build number in Pharo ... in fact I have been wondering about including a "build number" in Metacello version names, but I kind of like using the signature of the mcz file to replace the build number ... Saying that I have loaded version '1.0:ab.257' would be enough information to be able to look at the _exact_ configuration they have loaded! Dale On Mar 6, 2011, at 12:28 PM, Alexandre Bergel wrote: >> Don't get me wrong I like many small versions and I like traceability, I just don't believe that incrementing the metacallo version number enhances traceability... > > > Just to be sure. Consider the scenario using my development style: > > Version 1.0 is made of A-ab.1.mcz, B-ab.10.mcz and C-dkh.5.mcz > Version 1.1 is made of A-ab.1.mcz, B-ab.11.mcz and C-dkh.5.mcz > Version 1.2 is made of A-ab.2.mcz, B-ab.11.mcz and C-dkh.6.mcz > > There is a new version for each version. > Now, if we said we do not need to have Version 1.1, in order to reduce the numbering. > If Version 1.0 have all test green, and Version 1.2 some red ones. Without considering Version 1.1, it is more difficult to identify what has caused the red tests. > We can manually check A-ab.2.mcz, B-ab.11.mcz and C-dkh.6.mcz. But Version 1.1 says that A-ab.2.mcz is made to work with C-dkh.6.mcz. This is something very important that only an intermediate version can say. > > But if I am not missing something in the picture, then I feel having fewer explicit versions increases confusion if something got wrong. As I said, I am ready to accommodate my coding style with larger increment. > > Cheers, > Alexandre > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > |
«
Return to Metacello
|
1 view|%1 views
| Free forum by Nabble | Edit this page |