"repository editions" is finally permanent!

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

"repository editions" is finally permanent!

Chris Muller-3
"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

Reply | Threaded
Open this post in threaded view
|

Re: "repository editions" is finally permanent!

Bert Freudenberg
On Fri, Nov 25, 2016 at 3:40 AM, Chris Muller <[hidden email]> wrote:
"repository editions" is finally permanent!

Nice!
 
The 'mc history' menu was recently renamed to "browse repository
editions" because its only "history" if its retrieving them from the
trunk repository. 

I just published a tiny improvement: It now shows the timestamp and category in the editions list, just like in a method's version history.

Right after publishing I noticed we have two terms in the code base: "revisions" and now "editions". "Revisions" is an old term (Avi's method has a 2002 timestamp) but captures the intent just as well as "editions" I'd think. Maybe we would like to use that in the UI, too?

Actually I may have just introduced "edition" into the code base, in your code it's mostly named "history". Well, it's all fresh so we can fix it while it's hot. What do you think?

- Bert -


Reply | Threaded
Open this post in threaded view
|

Re: "repository editions" is finally permanent!

Bert Freudenberg
On Fri, Nov 25, 2016 at 12:02 PM, Bert Freudenberg <[hidden email]> wrote:
On Fri, Nov 25, 2016 at 3:40 AM, Chris Muller <[hidden email]> wrote:
"repository editions" is finally permanent!

Nice!
 
The 'mc history' menu was recently renamed to "browse repository
editions" because its only "history" if its retrieving them from the
trunk repository. 

I just published a tiny improvement: It now shows the timestamp and category in the editions list, just like in a method's version history.

Right after publishing I noticed we have two terms in the code base: "revisions" and now "editions". "Revisions" is an old term (Avi's method has a 2002 timestamp) but captures the intent just as well as "editions" I'd think. Maybe we would like to use that in the UI, too?

Actually I may have just introduced "edition" into the code base, in your code it's mostly named "history". Well, it's all fresh so we can fix it while it's hot. What do you think?

Actually I just fixed that, having "edition" in just one method name made no sense. So for now it's consistent, again.

- Bert -


Reply | Threaded
Open this post in threaded view
|

Re: "repository editions" is finally permanent!

Chris Muller-3
In reply to this post by Bert Freudenberg
Yes, we should make the API consistent with itself and, preferably,
the UI, too.  I prefer "editions" because, unlike revisions, it's
semantically inclusive of the earliest element, which isn't a revision
of anything.  However, that's pretty nitpicky and it seems Avi got
there first with "revisions".

I'll try to do that with the MC Configuration fix later today.  Thanks
for the feedback!  :)

On Fri, Nov 25, 2016 at 5:02 AM, Bert Freudenberg <[hidden email]> wrote:

> On Fri, Nov 25, 2016 at 3:40 AM, Chris Muller <[hidden email]> wrote:
>>
>> "repository editions" is finally permanent!
>
>
> Nice!
>
>>
>> The 'mc history' menu was recently renamed to "browse repository
>> editions" because its only "history" if its retrieving them from the
>> trunk repository.
>
>
> I just published a tiny improvement: It now shows the timestamp and category
> in the editions list, just like in a method's version history.
>
> Right after publishing I noticed we have two terms in the code base:
> "revisions" and now "editions". "Revisions" is an old term (Avi's method has
> a 2002 timestamp) but captures the intent just as well as "editions" I'd
> think. Maybe we would like to use that in the UI, too?
>
> Actually I may have just introduced "edition" into the code base, in your
> code it's mostly named "history". Well, it's all fresh so we can fix it
> while it's hot. What do you think?
>
> - Bert -
>
>
>

bpi
Reply | Threaded
Open this post in threaded view
|

Re: "repository editions" is finally permanent!

bpi
In reply to this post by Chris Muller-3
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 <[hidden email]>:
>
> "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
>


Reply | Threaded
Open this post in threaded view
|

Re: "repository editions" is finally permanent!

Chris Muller-4
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 <[hidden email]> 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 <[hidden email]>:
>>
>> "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
>>
>

bpi
Reply | Threaded
Open this post in threaded view
|

Re: "repository editions" is finally permanent!

bpi
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 <[hidden email]>:
>
> 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 <[hidden email]> 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 <[hidden email]>:
>>>
>>> "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
>>>
>>


Reply | Threaded
Open this post in threaded view
|

Re: "repository editions" is finally permanent!

Chris Muller-4
Oh right I forgot about "demote to bottom".  Maybe when that is invoked, it
should do it for all packages...?

> 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?

Perhaps when the updateURL is changed to "trunk", it should do that...