[squeak-dev] "repository editions" is finally permanent!
Bernhard Pieber
bernhard at pieber.com
Sun Oct 22 20:06:23 UTC 2017
Hi Chris,
Thanks for the fast answer. You are right, if I move the squeak50 under trunk then it works. There is a menu item named „demote to bottom“ which does this. The script below does what is necessary to make „repository editions“ work.
| repo50 |
repo50 := MCRepositoryGroup default repositories detect: [:each |
(each isKindOf: MCHttpRepository) and: [
each description = 'http://source.squeak.org/squeak50']].
MCWorkingCopy allManagers collect: [:wc |
wc repositoryGroup demoteRepository: repo50]
Why is the squeak50 repository still there in the trunk image? Any reason why it should not be removed from all packages in the trunk image?
Cheers,
Bernhard
> Am 22.10.2017 um 19:40 schrieb Chris Muller <ma.chris.m at gmail.com>:
>
> The editions are gonna be in the "trunk" repository, but this feature
> pulls the editions from the first MC repository listed in your
> Monticello browser for that package.
>
> So move the "trunk" repository to the top for that package; probably
> you have the "squeak50" repository listed first, which won't have any
> extra editions of that method.
>
> The easiest way right now to do that for all packages is to *edit* the
> "squeak50" repository to point to "trunk" instead; but you don't want
> to collide with an existing name even temporarily, so it takes 3
> steps:
>
> 1) rename "squeak50" to "tempname"
> 2) rename "trunk" to "squeak50"
> 3) rename "tempname" to "trunk"
>
> We really need a good way to do this better...
>
> On Sun, Oct 22, 2017 at 11:50 AM, Bernhard Pieber <bernhard at pieber.com> wrote:
>> Hi Chris,
>>
>> I want to try out your „repository editions“ feature in a current trunk image. However, I can’t find it. If I select SimpleBorder>>#initialize in a browser there is a menu item called „browse revisions“. However, when I select it I get an empty Revisions Browser. What am I missing?
>>
>> Cheers,
>> Bernhard
>>
>>> Am 25.11.2016 um 03:40 schrieb Chris Muller <asqueaker at gmail.com>:
>>>
>>> "repository editions" is finally permanent! This function formerly
>>> known as "mc history" appeared in 2013, but was clunky and unreliable
>>> and I didn't have time to fix it.
>>>
>>> Now with the recent server upgrade, I took the opportunity to upgrade
>>> the image to modern trunk, running under spur, with integration of the
>>> editions feature from directly within the image. It is now finally a
>>> permanent part of our source.squeak.org code repository. (Go ahead,
>>> try it!)
>>>
>>> It self-hosts its own code within our "ss" project. This is the exact
>>> same code loaded by the Personal Squeaksource package. Together can
>>> provide editions for ALL code (trunk and proprietary).
>>>
>>> The 'mc history' menu was recently renamed to "browse repository
>>> editions" because its only "history" if its retrieving them from the
>>> trunk repository. It selects from the first repository in the
>>> repository list of a package which can satisfy the editions request,
>>> so if you put inbox above trunk then you'll be looking at a list of
>>> "alternate editions" of that method (or class) existing in the Inbox,
>>> not the "history" from trunk. The new "demote to bottom" menu item
>>> can be used to adjust the order of the list.
>>>
>>> Nicolas wrote:
>>>
>>>> so you mean that we now browse all editions, including those which are not
>>>> in current MC version ancestors:
>>>> - those in concurrent branches
>>>
>>> Yes. And, I think this was always supported (when it worked!) -- In
>>> the server there is one big dictionary per Project (e.g., one for
>>> "trunk", one for "VMMaker", one for "inbox", etc.). The editions you
>>> see in the list are instances of MCMethodDefinition or
>>> MCClassDefinition which are keyed simply by their #description -- so
>>> for method editions this is {className. selector. classIsMeta}, and
>>> for class editions, simply its (class) name. Its valued by an
>>> OrderedCollection of all the editions. (hmm, that key might be too
>>> loose..)
>>>
>>>> - those in other packages (if the method was moved from one package to
>>>> another)
>>>
>>> So, yes, as long as the other package is in the same repository,
>>> they'll still be keyed by their same #description's.
>>>
>>> On Tue, 1 Nov 2016, Hans-Martin Mosner wrote:
>>>
>>>> Looks like there is a regression with raised and inset borders. The method #initialize in SimpleBorder sets baseColor to
>>>> ... snip...
>>>>
>>>> Levente, the method is from April 2016 and carries your initials - do you remember what the motivation for this change was?
>>>
>>> I'd been wanting encourage Hans-Martin to test this real-world use
>>> case for "browse origin" for the last weeks, now we finally can! :)
>>>
>>> 1) Bring up SimpleBorder, select the #initialize method.
>>> 2) Select "browse repository editions", a window with two editions
>>> is presented.
>>> 3) Select the one being asked about, "ul 4/7/2016 20:10" and select
>>> "browse origin".
>>>
>>> NOTE: "browse origin" is actually just "the earliest-known Version in
>>> which that definition appears." If a proper repository with all
>>> versions is kept, then it will be the origin.
>>>
>>> In this case, it appears Levente wrote very good "why" reasoning in the notes.
>>> _____
>>> The timeouts should all be fixed. Our code repository has never been
>>> in a better shape than now. Please feel free to use browse repository
>>> editions and origins with confidence they will work!
>>>
>>> Cheers!
>>> Chris
>>>
>>
More information about the Squeak-dev
mailing list
|