We appear to be all fixed, but I don't know why!  Did someone do something?

I was getting ready to append the following fix that would limit the output
of that one operation to the most recent 5000 items.  In
SSVersionListing>>#setProjects:.

setProjects: aCollection
    projects := aCollection.
    associations := Array streamContents: [ :stream |
        projects do: [ :project |
            self appendProject: project to: stream ] ].
    associations sort: [ :x :y | x value timestamp > y value timestamp ].
    "Limit to the last 5000 versions."
    associations := associations copyFrom: 1 to: (associations size min:
5000)

I've had the above typed into the browser in the production image, ready to
save, when I decided I wanted to observe the "broken-before -->
fixed-after" state change, broke-before was (is) no longer broken!

Strange.  So, I will hold off then.  If this fixes trunk development for
now, I'd rather invite the problem back to reveal itself again for better
understanding than put in any arbitrary fixes to "hide" it.  I'm not
working in trunk right now, if the problem returns, please email me again.

 - Chris


On Tue, Dec 27, 2022 at 3:23 PM Thiede, Christoph <
Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:

> Hi Chris,
>
>
> sorry for the misunderstanding! Some use case I was thinking of would be
> this: Somewhere in the mailing list archive, I find a reference to a very
> old Monticello version that I need to check out in order to understand why
> something was built or changed. Usually, I would open a repository browser
> on Trunk and scroll down until I find that really old version, just because
> it is more intuitive than using the API via efficient #versionNamed:.
> Will this still be possible through the UI with your intended change,
> regardless of the number of versions in the package?
>
>
> Apart from that, I can imagine that such a limitation would worsen the
> explorability of the database, but given that this is just meant to be a
> workaround and we have an urgent situation (of course, CI bundles
> and smalltalkCI for Trunk are broken as well) I don't think that this
> should be a real issue. In the long term, maybe add a small notice to the
> UI to indicate that the list is truncated.
>
>
> Best,
>
> Christoph
> ------------------------------
> *Von:* Chris Muller <ma.chris.m at gmail.com>
> *Gesendet:* Dienstag, 27. Dezember 2022 22:03:57
> *An:* Thiede, Christoph
> *Cc:* The general-purpose Squeak developers list;
> box-admins at lists.squeakfoundation.org
> *Betreff:* Re: [squeak-dev] trunk update stream appears to have become
> inaccessible
>
> Hi Christoph,
>
>> From the perspective of someone who has only gotten to know SqueakSource
>> from the client side: The possibility to enumerate *all* trunk versions is
>> important for me in several situations.
>>
> Would you mention or describe one or more of those situations, because...
>
>
>> It would be quite a shame if one could no longer access the full ancestry
>> of a version or browse an ancient version of any package through the UI.
>>
> ... this change would not affect the above use cases.  They could still be
> accomplished via the "History" button, because it accesses those very old
> versions *directly*, by name or UUID.  What we're talking about here is
> just the "list of files", NOT the list of ancestors, which we still have.
> The lists in the Repository browsers wouldn't show everything in the
> ancestry, but the ancestry is a better place to review that anyway.  I'm
> not convinced there is _any_ use case that needs a list of *all* Repository
> files (Versions) since the beginning of time.  If there is one, it's on an
> eternal linear degradation path, and some alternative approach should at
> least be considered.
>
>> The release notes generator in the ReleaseBuilder could also be affected,
>> I think.
>>
> It shouldn't be.  As above, it's in the ancestry.
>
>
>> With a view to modern REST and GraphQL APIs, would it be possible to add
>> support for some parameters to the requests in question to enable
>> pagination or filter the retrieved information vertically (i.e., leave out
>> some metadata)?
>>
> I'm sure it is, but right now I'm just looking for TSTTCPW for getting
> trunk development back online.  I think the round-robin with date-based
> balancing sounds like a good possibility for something that could be done
> quickly.
>
> Best,
>   Chris
>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20221227/342b787e/attachment-0001.html>