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/ [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 <ron at usmedrec.com>:
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 <marcel.taeumel at hpi.de [mailto:marcel.taeumel at hpi.de]> 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 <ron at usmedrec.com [mailto:ron at usmedrec.com]>:
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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200720/f2c5b92f/attachment.html>