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.
To compare 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.
For small well defined leaf projects it works well.
A leaf project is one that depends on other projects but does not have other projects depending on it.
Small projects are ones that can be packaged compactly.
For image maintenence several problems have arisen.
See the "Monticello and live systems" tread that Andreas started on squeak dev.
As the size of the package scales up the amount of time Monticello take increases more than linearly.
I have found Monticello hard to learn from outside.
Small mistakes can have large time penalties
There are so many different pieces (MC browsers, Repository browsers, etc., each with their own set of buttons. It is hard from the outside to form a mental model of what is going on.
Looking at all the buttions I want to know what to do when.
And why would I want to use this button as opposed to that one.
Monticello makes the naming of catagories critical for extention methods. It binds one to these names and packages at an early stage.
Monticello doesn't work well with the way changesets work with catagories.
When you add or subtract a catagory to an existing class or change the catagory of a method, then the change set containing that change also files out a reorganize catagorys for that class. The problem is that that reorganization touches the catagory information for all of the methods in the class even those not part of the changeset. Object and Morph are classes that have this happen often These classes have a lot of methods that are extentions of different packages. So you make a change that affects one of these classes and file out a changeset with a changesorter. Before your changeset is included in the main stream other changes also affect those classes and their method catagories. Then you filein or install your changeset and undo a lot of those catagory changes. Often this type of problem results in Monticello just dropping or losing methods.
Traditionally catagories have been treated as an after thought. They are not that visible in the image If a changeset mangled the catagories it didn't matter. The code was still there and would still work as you expected it. Monticello changes all that by loading onto the catagories the responsibility of determining which package they are in.
And of course that determines if methods are loaded or fall thru the crack.
MC has a few other gotcha's as well.
The identity of a package internally is by UUID not by the extern package name.
The access to a package from a repository is by external package name
You can name two packages with the same external name but they won't share the internal UUID and so won't be the same
You can have dual repository problems.
Two packages in two different repositories may have the same external name despite differing in their internal UUID.
These two packages can not be substituted for each other (even if the snapshot code is identical) because of the UUID difference
It will screw up the histories (or something)
You will not find out about it until you have commited a lot of time trying to get something to load.
MC does not even give you fair warning by displaying the uuid when you browse package historiies
You only get the external name.
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.
You need to maintain the image with changesets for speed.
McCready's gossamer condor flew the challenge course first be cause it could be repaired quickly and often.
Squeak is conceived to be lively and responsive.
Maintenence requires a lot of iterations for feedback and learning.
You need packages for discipline and clarity.
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.
