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: "
Time: 18 July 2020, 1:47:16.459316 pm
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.
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.
On Sat, Jul 18, 2020 at 12:55 PM Ron Teitelbaum <[hidden email]> wrote:
On Sat, Jul 18, 2020 at 7:39 PM Chris Muller <[hidden email]> wrote:
In reply to this post by Ron Teitelbaum
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.
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?
> 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-dtl.161 --- UUID 67fc
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.
Thanks. That all makes sense.
On Mon, Jul 20, 2020 at 9:52 AM Marcel Taeumel <[hidden email]> wrote:
|Free forum by Nabble||Edit this page|