On Wed, 6 Mar 2002, Lex Spoon wrote:

> Suppose I have the following changesets in my image:
> 
> 	URL
> 	HTML-Tokenizer
> 	HTML-Parser
> 	HTML-Formatter
> 
> I'm mainly working on the parser, so the current changeset is
> HTML-Parser.  However, I stumble across a bug somewhere in my code (I
> think that has happened once or twice.  Please, bear with me.).  After
> hitting implementors-of a few times, I'm looking at a blue message list
> window pointing at Url>>fragment.  Voila, this is it, just change one
> line of code....
> 
> Unfortunately the change will end up in the Parser changeset, even
> though it belongs in URL.  Why can't the system be set up to put all Url
> changes into the URL changeset?

Who says it can't? I used to work with just this type of changeset
management and it was incredibly useful:

	http://www.heeg.de/AppMan18/userGuide.htm

> Changeset-per-browser doesn't really help here.  All my changesets and
> message windows and such will be assigned to the Parser changeset.  Even
> if I have a URL browser floating around, I would have to dig through
> that browser to find the right method again, and that's even more work
> than switching the active changeset.
> 
> It seems like the system could easily guess which changeset to put
> something in, most of the time.  The big question, it seems, is whether
> there is a scheme that's so complicated to configure that it beats the
> point....

It just asks you in which changeset the method should live. And you can
still move around stuff, just like teh double change sorter.

-- Bert