[squeak-dev] "repository editions" is finally permanent!

Chris Muller asqueaker at gmail.com
Fri Nov 25 02:40:31 UTC 2016

"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

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


More information about the Squeak-dev mailing list