Change set smarts (was Re: Generalized Object Modules Design)

Bijan Parsia bparsia at email.unc.edu
Thu Mar 7 13:13:13 UTC 2002


On Thu, 7 Mar 2002, Richard A. O'Keefe wrote:

[snip]
> Browser 1 (green browser) bound to Html-Parser.
> Do implementors-of, get Browser 2 (blue implementors list) also bound
> to Html-Parser.  Repeat several times.
> Now in Browser N (blue) viewing Url>>fragment method, still bound
> to Html-Parser change set.  The change set name is shown in the title
> bar, so you can SEE that it is the wrong change set.
> Single keystroke or some kind of mouse click brings up a menu
> including "choose change set", select that, choose from list, done.
[snip]

In my original proposal note, I suggested that we add a "accept
in" command (analogous to a "save as" command) that let you override a
change on an ad hoc basis.

The tricky bit, of course, is that often (e.g., with lots of updates) the
suggestion list would be huge. However, a few heuristics, I think, could
save the day.

There's a bunch of stuff on using heuristics to help catelog email
messages (actually, via "similarity" tests). I can see such working well
for changesets (although the very simple heuristic "show changesets
'owned' buy the current author that contain the current class".

Hmm. You could even add a warning if the class in question *isn't* in the
browser's current changeset, but *is* in another changeset.

Whatever the actual default policies, having such hooks would be *very*
nice.

Cheers,
Bijan Parsia.




More information about the Squeak-dev mailing list