[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference smurf::buildhelp

Title:	USG buildhelp questions/answers

Moderator:	SMURF::FILTER

Created:	Mon Apr 26 1993
Last Modified:	Mon Jan 20 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	2763
Total number of notes:	5802

2194.0. "Re: Once again bdiff is misbehaving (for STEELOS this time)" by AOSG::FILTER (Automatic Posting Software - mail to flume::puck) Fri May 03 1996 15:49

Date Of Receipt: 	 5-APR-1996 11:31:29.54
From: 	SMURF::FLUME::jmf "Joshua M. Friedman OSF/UNIX SDE  05-Apr-1996 1129"
To: 	kucherov@DEC:.zko.flume
CC: 	odehelp@DEC:.zko.flume
Subj: 	Re: Once again bdiff is misbehaving (for STEELOS this time)

> I guess it is working as designed, but it is mighty confusing
> for bco and bdiff to use different versions!

Sergei, note that with no arguments, bdiff does use the same rev
as bco, but the bdiff we use for srequest "pretends" you're backed
by the submit tree.  If you just want, part of normal development, to
see how your file is different from what you started with, just do
	bdiff file      

and not  bdiff -r$NEW file

-josh

T.R Title User Personal
Name Date Lines

2194.1 Re: Once again bdiff is misbehaving (for STEELOS this time) AOSG::FILTER Automatic Posting Software - mail to flume::puck Fri May 03 1996 15:55 34

T.R	Title	User	Personal Name	Date	Lines
2194.1	Re: Once again bdiff is misbehaving (for STEELOS this time)	AOSG::FILTER	Automatic Posting Software - mail to flume::puck	`Fri May 03 1996 15:55`	34
	Date Of Receipt: 5-APR-1996 16:15:41.19 From: SMURF::GURU::kucherov "sergei kucherov 05-Apr-1996 1612" To: "Joshua M. Friedman, OSF/UNIX SDE 381-1548" <jmf@dec:.zko.guru> CC: kucherov@dec:.zko.guru, odehelp@dec:.zko.guru Subj: Re: Once again bdiff is misbehaving (for STEELOS this time) Thanks for the note about bdiff without the -r$NEW argument. I knew it, but a little extra reinforcement doesn't hurt. I now have a good idea on what to do when bdiff -r$NEW comes out different than bdiff (I need to either remerge my changes into a new sandbox backed by the non-nightly, or wait a day and remerge my changes into the new version in the nightly from the current sandbox). No big deal either way. The main goals are to: 1) make sure the bdiff in the srequest is accurate 2) avoid if possible bsubmit doing a source merge (then I would have to break out of it, do a merge and verify the results, retest, resend the srequest with the correct diffs (new line numbers mainly) and other minor complications which are not good after the srequest has been approved and the changes tested). I think developers may be able to get away with bsubmit doing a source merge, but it is way too dangerous for us in the support group to contemplate, since new patches may be sent to customers weekly with minimal additional testing (versus development having months of QA testing which would flush out any merge errors quite easily). When I see that bdiff -r$NEW puts unexpected diffs into the srequest form, I know what is likely happening and that I need to merge my changes with the latest before I continue with the srequest (probably the next day). Thanks for your explanations, sergei

Date Of Receipt: 	 5-APR-1996 16:15:41.19
From: 	SMURF::GURU::kucherov "sergei kucherov  05-Apr-1996 1612"
To: 	"Joshua M. Friedman, OSF/UNIX SDE 381-1548" <jmf@dec:.zko.guru>
CC: 	kucherov@dec:.zko.guru, odehelp@dec:.zko.guru
Subj: 	Re: Once again bdiff is misbehaving (for STEELOS this time)

Thanks for the note about bdiff without the -r$NEW argument.
I knew it, but a little extra reinforcement doesn't hurt.

I now have a good idea on what to do when bdiff -r$NEW comes
out different than bdiff (I need to either remerge my changes into
a new sandbox backed by the non-nightly, or wait a day and remerge
my changes into the new version in the nightly from the current sandbox).
No big deal either way. The main goals are to:
1) make sure the bdiff in the srequest is accurate
2) avoid if possible bsubmit doing a source merge
(then I would have to break out of it, do a merge and verify the results,
retest, resend the srequest with the correct diffs (new line numbers mainly)
and other minor complications which are not good after the srequest
has been approved and the changes tested). I think developers may be
able to get away with bsubmit doing a source merge, but it is way too
dangerous for us in the support group to contemplate, since new patches
may be sent to customers weekly with minimal additional testing
(versus development having months of QA testing which would flush out
any merge errors quite easily).

When I see that bdiff -r$NEW puts unexpected diffs into the srequest
form, I know what is likely happening and that I need to merge my
changes with the latest before I continue with the srequest (probably
the next day).

	Thanks for your explanations,
	sergei