[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]

Change management and regression errors.

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.)

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.