Conference smurf::buildhelp

2354.0. "Wish list for srequest" by AOSG::FILTER (Automatic Posting Software - mail to flume::puck) Mon Jun 24 1996 19:22

Date Of Receipt: 	21-JUN-1996 17:32:51.84
From: 	GURU::kucherov "sergei kucherov  21-Jun-1996 1714"
To: 	jmf@dec:.zko.guru, odehelp@dec:.zko.guru
CC: 	kucherov@dec:.zko.guru
Subj: 	Wish list for srequest

If you have a queue for srequest enhancements, can you add this?
If you don't have a queue for ode enhancements, can you create one,
and then add this item to the queue?

I wish srequest were changed to at least warn the user about any file
being changed (ie. that appears in the bdiff listing) that
has not been bci'd in the current sandbox
(or perhaps that is checked out locked -- a subtly different concept) 
since the private branch for that file started.

It seems awfully common that folks do a bco, srequest, bci sequence.
This means that the bdiff in the srequest either is missing
the header comment corresponding to the change or at least
that the final header comment being bsubmit'd will be different
from the comment being reviewed.

I will avoid naming culprits here, but I run into this problem a lot
(thus can't trust the header comment in the srequest), and to my mind
it is a tools problem. The tools, srequest in this case,
should warn about or prevent practices we think are substandard.

	sergei


P.S. By the way, I've been running successfully for months now with
my own private copy of srequest which has fixed the ^C interrupt
in vi problem which used to lose all edits and abort vi.
In my version the ^C in vi is intercepted by vi,
but does not get sent to the parent, srequest.
I'd have no qualms about improving my version of srequest to handle
my wish noted above, but it would solve nothing since the problem
is in how other folks use srequest.