Squeak
  links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
ChangeSorter vs. ChangeSet vs. Monticello
Last updated at 1:26 am UTC on 3 April 2009

The Stimulus

From: frits.swinkels Sent: January 21, 2004 Subject: ChangeSorter: bug or feature?

I loaded a changeset from an outside source and did some work in it. I then loaded a later changeset in which the outside source had done some more work: I loaded this changeset under a different name. I wanted to compare the two changesets in a DualChangeSorter. To my surprise both panes showed the same new source code for methods of the same name (and class), i.e. my work was wiped out.

On further inspection I noted that the changesets themselves (as opposed to the sorter which is a view on a changeset) point at the right code, i.e. the changeset knows precisely which version of a method it contains. It is the Sorter which goes out and gets the currently loaded code, whatever that is.

Am I missing a point here? Any suggestions for comparing two changesets for methods with the same name but different implementations? I can hear Avi answering Basic Squeak Development Tools, but I find the Changeset behaviour counter-intuitive.

The Responses

From: Boris Gaertner

To compare the a changeset with your image, you can select that changeset in the file list and select option "code-file browser" Your get a window that shows the contents of the file class-by-class. When you select a class and a method, the differences will be shown in red. You can also selectively file in methods with that tool.

From: Stefan Matthias Aust

You have a wrong "mental model" of what changesets are: They are just a name for a bunch of information about "these methods were changed on fileIn". So they always show a view of the current state of the source.

So for comparing, you need to have one version loaded, the other on disc and use e.g. the CodeBrowser to examine what changed. The best thing to do is, of course, to install Monticello and never look back ;-)

From: Goran Krampe

As others have said - ChangeSets - when they are in the image – are not so intuitive since they don't remember the actual code that they contain on disk.
...Your work (as you probably know) is still recoverable from the changes log.

... The general advice to use Monticello instead is of course the way to go. I used changesets before, and even if you know how they work they still manage to screw you over sometimes. Class renames anyone? Ouch. Anyway, Monticello is simply so much better in so many ways.

From: Doug Way

[It's sort of true that you “have the wrong mental model?], although as Fritz points out, the ChangeSet object actually points to the right code (the right CompiledMethod, which then knows its source pointer and can look up its source). So it's really more the fault of the Change Sorter that it only shows the current state of the source.


But yeah, everyone uses the ChangeSorters to work with changesets, so the current mental model is that changesets are just a list of methods (etc.) that have changed. But I wouldn't say that this is a particularly "good" mental model, in fact I'd consider it "bad". :-)

It would be interesting to "fix" the ChangeSorters so that they show the original source from the changesets. It is true though that everyone has gotten used to the ChangeSorters showing the current code, so there would have to be some getting used to the new behavior.

From "Jerome Peace" wiz

Monticello is not good for everything.




Now my point is not that Changesets are better than Monticello's packages. My point is that the two need to interoperate with each other.

Monticello needs to make it easy to work with change sets
Changesets and changesorters need to make it possible to work with monticello.

To help with the problem of MC category awareness. 3.10 adapted Changesets to list the package category of methods and classes. This is meant to help humans be aware of the categories they put their methods. The repairs are in the standard changesorters in 3.10. I don't know if omnibrowser changesorters report categories or not. wiz



In the context of maintaining an image, MC is an out of sequence tool.


That is to say you will always find you will have to do a lot of backtracking to make what would otherwise be small adjustments.

The case study for this would be 3.10's problems with fixing a poorly made repair.

The repair in question was Dan Ingalls suggestion that in many cases #== should actually be #= for nummerical comparrison.
The full repair cut across many packages and was attempted all at once rather than piece by piece.
This of course was a recipe for disaster and disaster struck.

Some of the #== converted to #= needed to be #==.
The symptom was obscure (loading projects would mess up identity dictionaries because a test that controlled rehashing now had a different outcome).
So it wasn't found until several more changes were made on top of the problematic one.

MC prevented the clock from being rolled back. The massive repair reverted and then the clock roll forward with the other repairs.
The large number of packages touched and the now accumulated histories of those packages complicated the issue the way a update stream of change sets would not.

This was the worst but not the only case of MC woes in building a release.

wiz