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 Monticello, but I find the Changeset behaviour counter-intuitive.
frits.swinkels frits.swinkels@shaw.ca asked
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 Monticello, but I find the Changeset behaviour counter-intuitive.
To compare the a changeset with your image, you can select that change set in the file list and select option "code-file browser" Your get a window that shows the contents of the file clas-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.
greetings, Boris
Am 22.01.2004 um 05:11 schrieb frits.swinkels:
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.
Hi,
You have a wrong "mental modell" of what changesets are: They are just a name for a bunch of information about "these methods were changed on fileIn". So they allways 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 ;-)
Marcus
-- Marcus Denker marcus@ira.uka.de
Marcus Denker wrote:
Am 22.01.2004 um 05:11 schrieb frits.swinkels:
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.
Hi,
You have a wrong "mental modell" of what changesets are: They are just a name for a bunch of information about "these methods were changed on fileIn". So they allways show a view of the current state of the source.
That's sort of true, 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 ChangeSorter 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.
- Doug
Doug Way wrote:
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.
- Doug
No, at least not everyone :-) I would love to see the suggested change to the ChangeSorters.
Attached is a change set which fixes the display of (old) code in the ChangeSorter, the DualChangeSorter and -by inheritance- the ChangeSetBrowser (called by CTL-B on the chandesorter menu). As well, one can file out the actual contents of a Changeset. It does not fix the message set browser called by CTL-b.
A note on implementation: the original implementation seemed to use setContents to set contents;) and selectedMethod to respond to changed. A override selectedMethod gets the real code. It is inserted into setContents at the proper spot.
ChangeSorter was on the steppingList, courtesy of the codeHolder. It was scanning for any possible change of the source of a method. That does not make sense if we are trying to keep the old code: stepping code made vacuous.
The way I tested this was as follows: before filing in the attached change set, I created a change set called OldChangeset. I put the ChangeSet class and ChangeSorter into this and filed it out. I then looked at the ChangeSorterFixes with the File Contents Browser (lovely tool that!) and filed it in. A dual change sorter then lets you look at methods on both sides; I did not figure out how to diff them.
Finally, I considered making this effort a ChangeSorter subclass, something like ImmutableChangeSorter. The problem is that I had to touch other classes, i.e. ChangeSet, because ChangeSorter delegates some copying and fileOut there.
Try it and tell me if an obvious angle was missed. Perhaps that is why Roel Wuyts developed his SystemChangeNotification after what he called "visiting the dark sides of Squeak";)
On Fri, 2004-01-23 at 05:43, C. David Shaffer wrote:
Doug Way wrote:
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.
- Doug
No, at least not everyone :-) I would love to see the suggested change to the ChangeSorters.
-- C. David Shaffer http://www.shaffer-consulting.com
"frits.swinkels" frits.swinkels@shaw.ca wrote:
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.
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.
Anyway, just wanted to mention that your work (as you probably know) is still recoverable from the changes log.
regards, Göran
PS. 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.
squeak-dev@lists.squeakfoundation.org
-
Boris Gaertner -
C. David Shaffer -
Doug Way -
frits.swinkels -
goran.krampe＠bluefish.se -
Marcus Denker