Hi Marcel,

Thanks.  That all makes sense.

Ron

On Mon, Jul 20, 2020 at 9:52 AM Marcel Taeumel <marcel.taeumel at hpi.de>
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 <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>
> 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>:
>> 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/b58b1c47/attachment.html>