Change management and regression errors.

[Ravi Pandya <ravi>]

Date: Sat, 5 May 90 16:01:31 PDT
   From: michael (Michael McClary)

   I just realized where some of the reappearing code might be coming from.

   I've noticed people file in in each other's changes between releases,
   accepting verbal assurances about what is affected, rather than testing
   this with a tool.

   If the filein contains a minor change to something you've just hacked, your
   changes are lost and you don't know it.

You won't catch it then, but the conflicts check at the next merge
will. (In either the old or the new change system.)

   (I have thought of a couple ways to deal with this, but want to check with
   Ravi about whether any are already supported or could be added without
   major hacking.  My impression is that the only available tool is "browse
   conflicts" and that it isn't used often because it's slow.)

	   michael
Browse conflicts should be significantly faster in the new release
(now that I've fixed the infinite loop). It is also less cumbersome --
you just start it and it checks back to the current baseline. It might
just be fast enough so that we can get into the habit of doing
conflicts checking on all fileins.
	--ravi