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 <
Christoph.Thiede at student.hpi.uni-potsdam.de> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20201112/e96907fe/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedImage.png
Type: image/png
Size: 50918 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20201112/e96907fe/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedImage.png
Type: image/png
Size: 17530 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20201112/e96907fe/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedImage.png
Type: image/png
Size: 27164 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20201112/e96907fe/attachment-0005.png>