Smalltalk › Squeak › Squeak - Dev

Bug: McmUpdater loads trunk updates into the wrong changesets

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

Christoph Thiede

Bug: McmUpdater loads trunk updates into the wrong changesets

I just noticed that the changesets generated by McmUpdater (I guess) are not assigned correctly to the new loaded patches:

Consider this:

versus this:

I suppose this is related to the update map mechanism? However, I'm quite sure this is a bug because I'd like to directly see to which trunk version a method version is related. If the changeset does not correspond to the method version, it should be named using the update map name.

What do you think? :-)

Best,

Christoph

Carpe Squeak!

codefrau

Re: Bug: McmUpdater loads trunk updates into the wrong changesets

That is an interesting observation.

MCMUpdater is designed to update the system as quickly as possible. One of its features is to not load every single MC version in sequence, but only the latest, if possible. That means all changes from what was in your image previously to what is being loaded will be lumped into the same exact changeset.

There are several ways around this.

The most simple one might be naming the changeset something like "Kernel-eem.1350-to-Kernel-eem.1361" if version 1361 is loaded on top of 1350. This would only require changes to MCLoader (IIRC it generates the changeset name).

A slower option would be to load each package version separately, which would slow down updating but put every change in a separate changeset. This would fail if intermediate versions are broken though. I would advise against it.

I'm not sure using the trunk version would be as useful. If you want to try that, the version would have to be updated before loading each package (trunk version is basically the sum of latest version numbers for all packages present in the latest update map), or you could rename the changesets after.

Using the update map name itself would be even less useful, since we only issue update maps to force loading certain versions before the update process can continue. In normal trunk development, the last published update map is re-used over and over to define the order of package updates, but the versions itself are typically newer than what's found in the stored map.

A wholly different approach would be to not show the changeset name in the browser, but to somehow get that version info from MC. MC does not directly support that, MC is not based on delta versioning but on full snapshots conceptually. However, IIRC Chris added some kind of version query to the Magma version of the squeaksource server though. Since that holds all method versions in a database it's easy to figure out in which version it changed.

Integrating the System Browser with MC might be a good idea going forward.

- Vanessa -

On Thu, Nov 12, 2020 at 7:56 AM Thiede, Christoph <[hidden email]> wrote:

I just noticed that the changesets generated by McmUpdater (I guess) are not assigned correctly to the new loaded patches:

Consider this:

versus this:

I suppose this is related to the update map mechanism? However, I'm quite sure this is a bug because I'd like to directly see to which trunk version a method version is related. If the changeset does not correspond to the method version, it should be named using the update map name.

What do you think? :-)

Best,

Christoph

Christoph Thiede

Re: Bug: McmUpdater loads trunk updates into the wrong changesets

Hi Vanessa,

> A wholly different approach would be to not show the changeset name in the browser, but to somehow get that version info from MC. MC does not directly support that, MC is not based on delta versioning but on full snapshots conceptually. However, IIRC Chris added some kind of version query to the Magma version of the squeaksource server though. Since that holds all method versions in a database it's easy to figure out in which version it changed.

> Integrating the System Browser with MC might be a good idea going forward.

Yeah, I have already had some similar thoughts in the past, it would be very useful to have an MC [and maybe also a Squot] integration to the Versions Browser. Use Case: For each version of a method, show the original MC version (inbox/trunk) [or the original git commit]. I have spent a lot of time doing this process manually a few times via the mailing list archive when such a feature would be really helpful for me.

I have no idea how big such a database that assigns a version pointer to each method version would be, but ideally, we could store and update this DB directly in the Trunk image. In my image, there are ca. 64k CompiledMethod instances, so the DB should be only a few megabytes large?

Alternatively, we could fetch this information dynamically, but I doubt this would be very convenient since it would require an active internet connection whenever you are browsing ...