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
|