Fix for Monticello Configuration - Question about Inbox

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Fix for Monticello Configuration - Question about Inbox

Ron Teitelbaum
Hi All,

I Added a fix but not sure I did it correctly.  Inbox has other non merged changes on it for Monticello Configurations.  Realized after the save that the number it picked was a duplicate of other changes added to inbox.

my change: "
Name: MonticelloConfigurations-RJT.163
Author: RJT
Time: 18 July 2020, 1:47:16.459316 pm
UUID: 87d7467d-cc80-7c4a-95a8-2a02c20366e1
Ancestors: MonticelloConfigurations-mt.162

Fix the up and down button (to change the load order) of Monticello Configurations so that it automatically selects the package that is moved.  This allows you to push the button more than once without having to select the package again.
"

What should I have done in this situation?  Do we just pick a later version number.  I'm assuming here that we do not merge in others changes to your own change set.  

Thanks for your help.

Ron Teitelbaum 


Reply | Threaded
Open this post in threaded view
|

Re: Fix for Monticello Configuration - Question about Inbox

Chris Muller-3
Generally, it's best for them to be based off of _some_ ancestor that's in the trunk, and not one that's only in the inbox.

If you find you have an ancestor of one in the inbox, the Reparent button before saving will let you choose an appropriate parent from the trunk repository, just be sure to choose one which is in its ancestry.

 - Chris

On Sat, Jul 18, 2020 at 12:55 PM Ron Teitelbaum <[hidden email]> wrote:
Hi All,

I Added a fix but not sure I did it correctly.  Inbox has other non merged changes on it for Monticello Configurations.  Realized after the save that the number it picked was a duplicate of other changes added to inbox.

my change: "
Name: MonticelloConfigurations-RJT.163
Author: RJT
Time: 18 July 2020, 1:47:16.459316 pm
UUID: 87d7467d-cc80-7c4a-95a8-2a02c20366e1
Ancestors: MonticelloConfigurations-mt.162

Fix the up and down button (to change the load order) of Monticello Configurations so that it automatically selects the package that is moved.  This allows you to push the button more than once without having to select the package again.
"

What should I have done in this situation?  Do we just pick a later version number.  I'm assuming here that we do not merge in others changes to your own change set.  

Thanks for your help.

Ron Teitelbaum 



Reply | Threaded
Open this post in threaded view
|

Re: Fix for Monticello Configuration - Question about Inbox

Ron Teitelbaum
Ok, thanks. 

On Sat, Jul 18, 2020 at 7:39 PM Chris Muller <[hidden email]> wrote:
Generally, it's best for them to be based off of _some_ ancestor that's in the trunk, and not one that's only in the inbox.

If you find you have an ancestor of one in the inbox, the Reparent button before saving will let you choose an appropriate parent from the trunk repository, just be sure to choose one which is in its ancestry.

 - Chris

On Sat, Jul 18, 2020 at 12:55 PM Ron Teitelbaum <[hidden email]> wrote:
Hi All,

I Added a fix but not sure I did it correctly.  Inbox has other non merged changes on it for Monticello Configurations.  Realized after the save that the number it picked was a duplicate of other changes added to inbox.

my change: "
Name: MonticelloConfigurations-RJT.163
Author: RJT
Time: 18 July 2020, 1:47:16.459316 pm
UUID: 87d7467d-cc80-7c4a-95a8-2a02c20366e1
Ancestors: MonticelloConfigurations-mt.162

Fix the up and down button (to change the load order) of Monticello Configurations so that it automatically selects the package that is moved.  This allows you to push the button more than once without having to select the package again.
"

What should I have done in this situation?  Do we just pick a later version number.  I'm assuming here that we do not merge in others changes to your own change set.  

Thanks for your help.

Ron Teitelbaum 



Reply | Threaded
Open this post in threaded view
|

Re: Fix for Monticello Configuration - Question about Inbox

marcel.taeumel
In reply to this post by Ron Teitelbaum
Hi Ron.

Thank you! =)

Realized after the save that the number it picked was a duplicate of other changes added to inbox.

Make sure to have all three repos in that package's repository group: Trunk, Inbox, Treated. Then the automatic version number calculation will work. Your local package cache will be considered, too.

A small gap in a new version number is okay.

Best,
Marcel

Am 18.07.2020 19:55:41 schrieb Ron Teitelbaum <[hidden email]>:

Hi All,

I Added a fix but not sure I did it correctly.  Inbox has other non merged changes on it for Monticello Configurations.  Realized after the save that the number it picked was a duplicate of other changes added to inbox.

my change: "
Name: MonticelloConfigurations-RJT.163
Author: RJT
Time: 18 July 2020, 1:47:16.459316 pm
UUID: 87d7467d-cc80-7c4a-95a8-2a02c20366e1
Ancestors: MonticelloConfigurations-mt.162

Fix the up and down button (to change the load order) of Monticello Configurations so that it automatically selects the package that is moved.  This allows you to push the button more than once without having to select the package again.
"

What should I have done in this situation?  Do we just pick a later version number.  I'm assuming here that we do not merge in others changes to your own change set.  

Thanks for your help.

Ron Teitelbaum 


Reply | Threaded
Open this post in threaded view
|

Re: Fix for Monticello Configuration - Question about Inbox

Ron Teitelbaum
Hi Marcel,

Thanks for the suggestion.  I wasn't aware of Treated but I went and looked it up.  So things that are sent to Inbox are then moved to either Trunk if accepted or Treated if not accepted.  Did I get that right?  

So someone that wants to contribute should load (or merge) the trunk latest version but also add Inbox and Treated as repositories to the package for automatic monticello numbering.  Then save the change verifying that only their changes show up.  The number that it picks should be an acceptable number for sending changes?  Should we also verify that the number is greater than the last number in Inbox?

Thanks!

Ron

On Mon, Jul 20, 2020 at 5:02 AM Marcel Taeumel <[hidden email]> wrote:
Hi Ron.

Thank you! =)

Realized after the save that the number it picked was a duplicate of other changes added to inbox.

Make sure to have all three repos in that package's repository group: Trunk, Inbox, Treated. Then the automatic version number calculation will work. Your local package cache will be considered, too.

A small gap in a new version number is okay.

Best,
Marcel

Am 18.07.2020 19:55:41 schrieb Ron Teitelbaum <[hidden email]>:

Hi All,

I Added a fix but not sure I did it correctly.  Inbox has other non merged changes on it for Monticello Configurations.  Realized after the save that the number it picked was a duplicate of other changes added to inbox.

my change: "
Name: MonticelloConfigurations-RJT.163
Author: RJT
Time: 18 July 2020, 1:47:16.459316 pm
UUID: 87d7467d-cc80-7c4a-95a8-2a02c20366e1
Ancestors: MonticelloConfigurations-mt.162

Fix the up and down button (to change the load order) of Monticello Configurations so that it automatically selects the package that is moved.  This allows you to push the button more than once without having to select the package again.
"

What should I have done in this situation?  Do we just pick a later version number.  I'm assuming here that we do not merge in others changes to your own change set.  

Thanks for your help.

Ron Teitelbaum 



Reply | Threaded
Open this post in threaded view
|

Re: Fix for Monticello Configuration - Question about Inbox

marcel.taeumel
Hi Ron.

 Did I get that right?  

Yes. And a version gets also moved to Treated if that contribution was already merged otherwise, maybe manually. Or if it is a duplicate. Or no longer valid. :-)

The number that it picks should be an acceptable number for sending changes?  

Yes, it should be.

> Should we also verify that the number is greater than the last number in Inbox?

Your author initials ... kind of ... represent their own space for version numbers -- except that, for each new version, you should consider the biggest number in current Trunk. +1. :-) We do that to compute the overall build number by adding up all the most recent version numbers from all packages in the "update" map (aka. Monticello Configuration). "Squeak-Version" is the package for correcting that build number, e.g., when removing a package.

So, conflicts mostly happen for a single author who forgot about a version in the local package cache or Inbox or Treated. We can still resolve those conflicts because each version has a UUID. However, the more compact "author.number" form -- stored in the MCZ filename -- is used to find the most recent version without having to open up the MCZ file. The number is not that UUID for the above reason and to keep the file name human-readable. Sort-by-name quickly gives you the name of the newest version.

Duplicate version numbers with different authors are possible BUT should be merged as quickly as possible. :-) So "abc.123" and "def.123" should be merged to "foo.124" to not confuse the in-image update process.

Here is more information: https://squeak.org/development_process/

In Trunk we have this:

MonticelloConfigurations-mt.162
MonticelloConfigurations-dtl.161 --- UUID 67fc
MonticelloConfigurations-mt.160
MonticelloConfigurations-mt.159
...

In Inbox we have this:

MonticelloConfigurations-RJT.163 --- for MonticelloConfigurations-mt.162 --- OK!

MonticelloConfigurations-dtl.160 --- for MonticelloConfigurations-mt.159 --- OK!
MonticelloConfigurations-dtl.161 --- UUID 303c --- for MonticelloConfigurations-dtl.160 --- NAME CONFLICT!
MonticelloConfigurations-dtl.162 --- for MonticelloConfigurations-dtl.161 w/ UUID 303c --- ANCESTOR CONFLICT!
MonticelloConfigurations-dtl.163 --- for MonticelloConfigurations-dtl.162 --- INDIRECT ANCESTOR CONFLICT!
MonticelloConfigurations-dtl.164 --- for MonticelloConfigurations-dtl.163 --- INDIRECT ANCESTOR CONFLICT!
MonticelloConfigurations-dtl.165 --- for MonticelloConfigurations-dtl.164 --- INDIRECT ANCESTOR CONFLICT!
MonticelloConfigurations-dtl.166 --- for MonticelloConfigurations-dtl.165 --- INDIRECT ANCESTOR CONFLICT!
MonticelloConfigurations-dtl.167 --- for MonticelloConfigurations-dtl.166 --- INDIRECT ANCESTOR CONFLICT!

Well, it is correct that improvements to existing inbox contributions build on those versions and not on the recent trunk. However, in this case, dtl.161 and dtl.162 introduced a hidden conflict in (file) name and ancestry, which renders all following dtl.* commits problematic. A manual merge would be necessary. All those conflicting versions should be moved to Treated after the merge of their contents.

Best,
Marcel

Am 20.07.2020 15:15:10 schrieb Ron Teitelbaum <[hidden email]>:

Hi Marcel,

Thanks for the suggestion.  I wasn't aware of Treated but I went and looked it up.  So things that are sent to Inbox are then moved to either Trunk if accepted or Treated if not accepted.  Did I get that right?  

So someone that wants to contribute should load (or merge) the trunk latest version but also add Inbox and Treated as repositories to the package for automatic monticello numbering.  Then save the change verifying that only their changes show up.  The number that it picks should be an acceptable number for sending changes?  Should we also verify that the number is greater than the last number in Inbox?

Thanks!

Ron

On Mon, Jul 20, 2020 at 5:02 AM Marcel Taeumel <[hidden email]> wrote:
Hi Ron.

Thank you! =)

Realized after the save that the number it picked was a duplicate of other changes added to inbox.

Make sure to have all three repos in that package's repository group: Trunk, Inbox, Treated. Then the automatic version number calculation will work. Your local package cache will be considered, too.

A small gap in a new version number is okay.

Best,
Marcel

Am 18.07.2020 19:55:41 schrieb Ron Teitelbaum <[hidden email]>:

Hi All,

I Added a fix but not sure I did it correctly.  Inbox has other non merged changes on it for Monticello Configurations.  Realized after the save that the number it picked was a duplicate of other changes added to inbox.

my change: "
Name: MonticelloConfigurations-RJT.163
Author: RJT
Time: 18 July 2020, 1:47:16.459316 pm
UUID: 87d7467d-cc80-7c4a-95a8-2a02c20366e1
Ancestors: MonticelloConfigurations-mt.162

Fix the up and down button (to change the load order) of Monticello Configurations so that it automatically selects the package that is moved.  This allows you to push the button more than once without having to select the package again.
"

What should I have done in this situation?  Do we just pick a later version number.  I'm assuming here that we do not merge in others changes to your own change set.  

Thanks for your help.

Ron Teitelbaum 



Reply | Threaded
Open this post in threaded view
|

Re: Fix for Monticello Configuration - Question about Inbox

Ron Teitelbaum
Hi Marcel,

Thanks.  That all makes sense.

Ron

On Mon, Jul 20, 2020 at 9:52 AM Marcel Taeumel <[hidden email]> wrote:
Hi Ron.

 Did I get that right?  

Yes. And a version gets also moved to Treated if that contribution was already merged otherwise, maybe manually. Or if it is a duplicate. Or no longer valid. :-)

The number that it picks should be an acceptable number for sending changes?  

Yes, it should be.

> Should we also verify that the number is greater than the last number in Inbox?

Your author initials ... kind of ... represent their own space for version numbers -- except that, for each new version, you should consider the biggest number in current Trunk. +1. :-) We do that to compute the overall build number by adding up all the most recent version numbers from all packages in the "update" map (aka. Monticello Configuration). "Squeak-Version" is the package for correcting that build number, e.g., when removing a package.

So, conflicts mostly happen for a single author who forgot about a version in the local package cache or Inbox or Treated. We can still resolve those conflicts because each version has a UUID. However, the more compact "author.number" form -- stored in the MCZ filename -- is used to find the most recent version without having to open up the MCZ file. The number is not that UUID for the above reason and to keep the file name human-readable. Sort-by-name quickly gives you the name of the newest version.

Duplicate version numbers with different authors are possible BUT should be merged as quickly as possible. :-) So "abc.123" and "def.123" should be merged to "foo.124" to not confuse the in-image update process.

Here is more information: https://squeak.org/development_process/

In Trunk we have this:

MonticelloConfigurations-mt.162
MonticelloConfigurations-dtl.161 --- UUID 67fc
MonticelloConfigurations-mt.160
MonticelloConfigurations-mt.159
...

In Inbox we have this:

MonticelloConfigurations-RJT.163 --- for MonticelloConfigurations-mt.162 --- OK!

MonticelloConfigurations-dtl.160 --- for MonticelloConfigurations-mt.159 --- OK!
MonticelloConfigurations-dtl.161 --- UUID 303c --- for MonticelloConfigurations-dtl.160 --- NAME CONFLICT!
MonticelloConfigurations-dtl.162 --- for MonticelloConfigurations-dtl.161 w/ UUID 303c --- ANCESTOR CONFLICT!
MonticelloConfigurations-dtl.163 --- for MonticelloConfigurations-dtl.162 --- INDIRECT ANCESTOR CONFLICT!
MonticelloConfigurations-dtl.164 --- for MonticelloConfigurations-dtl.163 --- INDIRECT ANCESTOR CONFLICT!
MonticelloConfigurations-dtl.165 --- for MonticelloConfigurations-dtl.164 --- INDIRECT ANCESTOR CONFLICT!
MonticelloConfigurations-dtl.166 --- for MonticelloConfigurations-dtl.165 --- INDIRECT ANCESTOR CONFLICT!
MonticelloConfigurations-dtl.167 --- for MonticelloConfigurations-dtl.166 --- INDIRECT ANCESTOR CONFLICT!

Well, it is correct that improvements to existing inbox contributions build on those versions and not on the recent trunk. However, in this case, dtl.161 and dtl.162 introduced a hidden conflict in (file) name and ancestry, which renders all following dtl.* commits problematic. A manual merge would be necessary. All those conflicting versions should be moved to Treated after the merge of their contents.

Best,
Marcel

Am 20.07.2020 15:15:10 schrieb Ron Teitelbaum <[hidden email]>:

Hi Marcel,

Thanks for the suggestion.  I wasn't aware of Treated but I went and looked it up.  So things that are sent to Inbox are then moved to either Trunk if accepted or Treated if not accepted.  Did I get that right?  

So someone that wants to contribute should load (or merge) the trunk latest version but also add Inbox and Treated as repositories to the package for automatic monticello numbering.  Then save the change verifying that only their changes show up.  The number that it picks should be an acceptable number for sending changes?  Should we also verify that the number is greater than the last number in Inbox?

Thanks!

Ron

On Mon, Jul 20, 2020 at 5:02 AM Marcel Taeumel <[hidden email]> wrote:
Hi Ron.

Thank you! =)

Realized after the save that the number it picked was a duplicate of other changes added to inbox.

Make sure to have all three repos in that package's repository group: Trunk, Inbox, Treated. Then the automatic version number calculation will work. Your local package cache will be considered, too.

A small gap in a new version number is okay.

Best,
Marcel

Am 18.07.2020 19:55:41 schrieb Ron Teitelbaum <[hidden email]>:

Hi All,

I Added a fix but not sure I did it correctly.  Inbox has other non merged changes on it for Monticello Configurations.  Realized after the save that the number it picked was a duplicate of other changes added to inbox.

my change: "
Name: MonticelloConfigurations-RJT.163
Author: RJT
Time: 18 July 2020, 1:47:16.459316 pm
UUID: 87d7467d-cc80-7c4a-95a8-2a02c20366e1
Ancestors: MonticelloConfigurations-mt.162

Fix the up and down button (to change the load order) of Monticello Configurations so that it automatically selects the package that is moved.  This allows you to push the button more than once without having to select the package again.
"

What should I have done in this situation?  Do we just pick a later version number.  I'm assuming here that we do not merge in others changes to your own change set.  

Thanks for your help.

Ron Teitelbaum