"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
On Fri, Nov 25, 2016 at 3:40 AM, Chris Muller asqueaker@gmail.com 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 -
On Fri, Nov 25, 2016 at 12:02 PM, Bert Freudenberg bert@freudenbergs.de wrote:
On Fri, Nov 25, 2016 at 3:40 AM, Chris Muller asqueaker@gmail.com 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 -
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 bert@freudenbergs.de wrote:
On Fri, Nov 25, 2016 at 3:40 AM, Chris Muller asqueaker@gmail.com 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 -
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@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! :)
- Bring up SimpleBorder, select the #initialize method.
- 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
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@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@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! :)
- Bring up SimpleBorder, select the #initialize method.
- 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
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@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:
- rename "squeak50" to "tempname"
- rename "trunk" to "squeak50"
- 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@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@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! :)
- Bring up SimpleBorder, select the #initialize method.
- 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
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...
squeak-dev@lists.squeakfoundation.org
-
Bernhard Pieber -
Bert Freudenberg -
Chris Muller -
Chris Muller