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