Conference smurf::buildhelp

Date Of Receipt: 	 3-MAY-1996 00:18:28.90
From: 	ALPHA::"eve@wdec.locus.com" "2-May-1996 2120"
To: 	odehelp@zk3.dec.com
CC: 	dzung@wdec.locus.com, eve@wdec.locus.com, kucherov@guru.zk3.dec.com
Subj: 	how to fix a bsubmit with mismatched file defect #

Hello,
One of the engineers that reports to me made a mistake in a bsubmit he
did on 5/1. He had two srequests, v32csupportos-172-nguyen and
v32csupportos-183-nguyen, which modified usr/sbin/lpd/lpr.c and
usr/sbin/lpd/common.c, respectively. He specified the wrong srequest when
he did the bsubmit for common.c. (He had actually intended to bsbumit
lpr.c first and screwed up.)

What he did was:

bsubmit -auto_out common.c -defect v32csupportos-172-nguyen

when he should have said either:
1)bsubmit -auto_out common.c -defect v32csupportos-183-nguyen
		or
2)bsubmit -auto_out lpr.c -defect v32csupportos-172-nguyen

Either 1) or 2) would have been proper since both files were in ./usr/sbin/lpd

When he went back into his sandbox today to bsubmit common.c, bsubmit
complained because it wasn't in his .BCSset* .BCSlog* files. I'm not sure
whether this contributed to the state described below or not...

What seems to have happened is 1)common.c got bsubmitted but associated
with the wrong srequest, 2) common.c got outdated,  and 3) lpr.c disappeared
from .BCSset* and .BCSlog*. 

Does item #3 mean lpr.c was outdated? Is his private branch version still
accessible by its full version name (presumably in the -172- srequest)?

What do we need to do to try to cleanup/recover from this mess?

Evelyn Walton

Date Of Receipt: 	 3-MAY-1996 12:48:07.37
From: 	ALPHA::"jmf@zk3.dec.com" "Joshua M. Friedman OSF/UNIX SDE  03-May-1996 1241"
To: 	eve@wdec.locus.com
CC: 	dzung@wdec.locus.com, kucherov@guru.zk3.dec.com, odehelp@zk3.dec.com
Subj: 	re:: how to fix a bsubmit with mismatched file defect #

Evelyn, if all the submits are in ok, just do srequest -updates for
both forms and swap the contents.  If there are incorrect submits, then
do more submits to line everything up correctly.

If you need more help, please mail to odehelp.  Thanks...

	-josh


------- Forwarded Message

Date: Thu, 2 May 96 21:20:40 -0700
From: eve@wdec.locus.com (Evelyn Walton)
Message-Id: <9605030420.AA29523@locusla.wdec.locus.com>
To: odehelp@zk3.dec.com
Subject: how to fix a bsubmit with mismatched file defect #
Cc: dzung@wdec.locus.com, eve@wdec.locus.com, kucherov@guru.zk3.dec.com

Hello,
One of the engineers that reports to me made a mistake in a bsubmit he
did on 5/1. He had two srequests, v32csupportos-172-nguyen and
v32csupportos-183-nguyen, which modified usr/sbin/lpd/lpr.c and
usr/sbin/lpd/common.c, respectively. He specified the wrong srequest when
he did the bsubmit for common.c. (He had actually intended to bsbumit
lpr.c first and screwed up.)

What he did was:

bsubmit -auto_out common.c -defect v32csupportos-172-nguyen

when he should have said either:
1)bsubmit -auto_out common.c -defect v32csupportos-183-nguyen
		or
2)bsubmit -auto_out lpr.c -defect v32csupportos-172-nguyen

Either 1) or 2) would have been proper since both files were in ./usr/sbin/lpd

When he went back into his sandbox today to bsubmit common.c, bsubmit
complained because it wasn't in his .BCSset* .BCSlog* files. I'm not sure
whether this contributed to the state described below or not...

What seems to have happened is 1)common.c got bsubmitted but associated
with the wrong srequest, 2) common.c got outdated,  and 3) lpr.c disappeared
from .BCSset* and .BCSlog*. 

Does item #3 mean lpr.c was outdated? Is his private branch version still
accessible by its full version name (presumably in the -172- srequest)?

What do we need to do to try to cleanup/recover from this mess?

Evelyn Walton


------- End of Forwarded Message

Date Of Receipt: 	 3-MAY-1996 13:13:46.07
From: 	GURU::kucherov "sergei kucherov  03-May-1996 1305"
To: 	"Joshua M. Friedman, OSF/UNIX SDE 381-1548" <jmf@dec:.zko.guru>
CC: 	eve@wdec.locus.com, dzung@wdec.locus.com, kucherov@guru.zk3.dec.com,
	odehelp@zk3.dec.com, kucherov@dec:.zko.guru
Subj: 	Re: : how to fix a bsubmit with mismatched file defect #
> What he did was: 	

> 
> bsubmit -auto_out common.c -defect v32csupportos-172-nguyen
> ...
> 3) lpr.c disappeared from .BCSset* and .BCSlog*. 

If you bsubmit only file A and file B disappears from .BCS*
*and* if you can reproduce this (which is quite doubtful)
then you need to enter a top priority ODE bug using the gen-ptt tool.
I suspect some other commands were issued other than the one
bsubmit you mentioned above (eg. bsubmit ... -all)
in order for "3)" to have happened.
It's a *serious* bug if you can reproduce it.

	sergei

Date Of Receipt: 	 3-MAY-1996 14:00:34.31
From: 	ALPHA::"eve@wdec.locus.com" "3-May-1996 1102"
To: 	jmf@locusfilter.zk3.dec.com, kucherov@locusfilter.zk3.dec.com
CC: 	dzung@wdec.locus.com, eve@wdec.locus.com, odehelp@zk3.dec.com
Subj: 	Re: : how to fix a bsubmit with mismatched file defect #
Josh, Sergei: 	

I doubt -all was used since there is still one file left in the .BCS*
files and I'm pretty sure it's not a new addition (after the bsubmit).

Does bsubmit actually DO anything with the defect number you give it other
than log it to bsubmit.log?

The new common.c code seems to be in the submit pool OK. Our
main concern is lpr.c. We don't really understand the technical details
of the private branches enough to be able to definitively figure out whether
the version of lpr.c that was approved in the *172 srequest is around any
more except maybe read-only in the sandbox. Is there an easy way of telling
this?

If the version of lpr.c we already had approval to check in it isn't available
anywhere where ode will automatically get it when we try the bsubmit, then can
you confirm whether this is the right sequence of things to do?
bci lpr.c
put the right contents into lpr.c
bco lpr.c
srequest -update somehow after figuring out how to talk srequest into updating
	 the stuff it does automatically when you ran it the first time --
	diffs, version number, etc. What's the best way to do this?
bsubmit lpr.c -defect v32csupportos-172-nguyen

Is there any way to undo a bsubmit other than to bco the affected files,
then either do a null bci or dump the proper contents back into the checked
out file before doing a bci, then redoing the bsubmit with the right defect
number? 

Thanks.

Evelyn Walton

Date Of Receipt: 	 3-MAY-1996 14:40:17.86
From: 	GURU::kucherov "sergei kucherov  03-May-1996 1433"
To: 	eve@wdec.locus.com (Evelyn Walton)
CC: 	jmf@dec:.zko.guru, kucherov@dec:.zko.guru, dzung@wdec.locus.com,
	odehelp@zk3.dec.com
Subj: 	Re: : how to fix a bsubmit with mismatched file defect #

> Does bsubmit actually DO anything with the defect number you give it other
> than log it to bsubmit.log?

No.
Though the srequest should drive the bsubmit directly, it does not currently.
This is one of my pet peeves, so I won't say anything further
on this deficiency.
(bsubmit may check that the defect number is legal and approved,
but doesn't check what you are submitting against the contents
of the srequest).

> whether the version of lpr.c that was approved in the *172 srequest
> is around any more except maybe read-only in the sandbox.

lpr.c hasn't gotten into the v32c pool (ie. not bsubmitted).
blog doesn't show that nguyen has it locked.
The sandbox files show that it is not bco'd or bci'd.

> you confirm whether this is the right sequence of things to do?

Luckily, the srequest has the diffs for lpr.c in it.
Thus it will be quite easy to do bco, apply changes, then bci.
Then this should finish it up:
## Do not bother with the srequest -update unless you are changing the
## contents
##srequest -update v32csupportos-172-nguyen

bsubmit -defect v32csupportos-172-nguyen lpr.c

	sergei

P.S.
> The new common.c code seems to be in the submit pool OK.

Not fully OK. A new bsubmit for common.c perhaps should be done
with a correct defect number. Right now the bsubmit.log
shows that common.c was bsubmit'd with the defect
v32csupportos-172-nguyen . I will leave this issue to your (and Josh's)
judgement and will now leave this loop for others to continue.

Date Of Receipt: 	 3-MAY-1996 21:40:51.58
From: 	GURU::kucherov "sergei kucherov  03-May-1996 2132"
To: 	kucherov@dec:.zko.guru
CC: 	eve@wdec.locus.com, overman@dec:.zko.guru, jmf@dec:.zko.guru,
	dzung@wdec.locus.com, odehelp@zk3.dec.com
Subj: 	Re: : how to fix a bsubmit with mismatched file defect #

A few more ideas came to mind regarding ODE anomalies.

1) I use ODE on my workstation on a non-NFS-mounted (ie. local) partition.
It works great.
I can backup my files quite trivially and fast, since I only need
to backup non-symlinks. For example:
tar -cvf ~/sandboxes.backup.tar `find top_of_all_sb/*/src -type f`

It's should be OK to put your sandboxes on guru, but then:
Are you logged in to guru when you do bco, bci, bsubmit?
(Evelyn said recently that Locus folks were only building locally,
and all bco, bci, bsubmit commands were being done on guru, which is safe).

2) You might want to check your .../src/.BCS* files for sanity.
After you bci a file, you should see an appropriate entry
in src/.BCSlog* . After you bco a file (and until you "undo" the file
or bsubmit it) you should see an appropriate entry in src/.BCSconfig .
Otherwise bsubmit will croak if it doesn't see your file in .BCSconfig .

3) To the ODE "beginners" here (which includes myself) I recommend
a rule: If you have done a bco and/or bci to a file in a sandbox
and want to start over (eg. if ODE misbehaves or your header comment
isn't the way you want it), then undo all your work on it
(first copy your changes to a different file name to help with
redoing the work later). To undo all your work on file foo.c, do:
	bcs -u -o foo.c
and ignore a possible message: "rcs error: no lock set on revision ..."
(since there is no lock if you have done the bci).
What I left out of my prior mail is to do the "bcs -u -o" on lpr.c
and then start from a clean slate with "bco", "bci", etc.
At each stage, look at all your .../src/.BCS* files to see if the
right thing has been done. Then you can report at which step precisely
you're running into a problem. Perhaps ODE does have a real bug
(or NFS ...).
But to prove it, you'll have to use "script" or another way to
capture exactly your commands and in-between b* commands, "more"
the .../src/.BCS* files ("more" will identify each file before
outputting it).

	Good luck,
	sergei


P.S.
4) Finally, the easiest way to shoot yourself in ODE is to misuse "set"s.
I just poked around ~nguyen/sb (many thanks for keeping it readable
for everyone), and noticed some "set" anomalies that eventually
will cause you grief (as it did me).

A) ~nguyen/.sandboxrc does not apply the second "patch" that I sent
Evelyn mail on which works around an easy way to shoot yourself.
Also it doesn't apply the first patch I recommended earlier.
You will end up suffering. Get Evelyn to dredge up my 2 strong
recommendations on editing .sandboxrc. Or you can look at mine (~kucherov).
Needless to say, you don't have to apply the patches, but
you'll eventually end up wasting my time -- which I do care about.

B) I did this to see if you were potentially abusing sets:
soil> more ~nguyen/sb/*/rc_files/sets
::::::::::::::
/home/nguyen/sb/v13b/rc_files/sets
::::::::::::::
default Nguyen_Dzung_v13b
set Nguyen_Dzung_v13b .
::::::::::::::
/home/nguyen/sb/v20/rc_files/sets
::::::::::::::
default Nguyen_Dzung_v20
set Nguyen_Dzung_v20 .
::::::::::::::
/home/nguyen/sb/v20b/rc_files/sets
::::::::::::::
default Nguyen_Dzung_v20b
set Nguyen_Dzung_v20b .
::::::::::::::
/home/nguyen/sb/v30/rc_files/sets
::::::::::::::
default Nguyen_Dzung_v30
set Nguyen_Dzung_v30 .
set Nguyen_Dzung_v32 .
set Nguyen_Dzung_v3.2 .
::::::::::::::
/home/nguyen/sb/v32/rc_files/sets
::::::::::::::
default Nguyen_Dzung_v32
set Nguyen_Dzung_v32 .
::::::::::::::
/home/nguyen/sb/v32c/rc_files/sets
::::::::::::::
default Nguyen_Dzung_v32c
set Nguyen_Dzung_v32c .
set Nguyen_Dzung_v32de1 .
::::::::::::::
/home/nguyen/sb/v32de1/rc_files/sets
::::::::::::::
default Nguyen_Dzung_v32de1
set Nguyen_Dzung_v32de1 .
::::::::::::::
/home/nguyen/sb/v40/rc_files/sets
::::::::::::::
default Nguyen_Dzung_v40
set Nguyen_Dzung_v40 .
::::::::::::::
/home/nguyen/sb/v_ptn/rc_files/sets
::::::::::::::
default Nguyen_Dzung_v_ptn
set Nguyen_Dzung_v_ptn .

It looks a bit odd to see a set Nguyen_Dzung_v32de1 inside
a v32c sandbox! Similarly, the sets in the v30 sandbox
have names that someday may cause you trouble.
If you do "workon v32de1" you will end up in a v32c sandbox,
wherease "workon -sb v32de1" will put you in the v32de1 sandbox.
I'm not claiming your set names *are* causing you problems;
but unless you're really expert with ODE I predict they will.

By the way, if you have no files associated with a set (see .BCSset*)
then you can just remove the set by editing .../rc_files/sets (carefully!)
to delete the line defining the set. The odehelp mail alias may
be able to clue you in to the "proper" way to remove a set.
I, as a beginner myself, do not know the "proper" method.
But recently I have used the editing the "sets" file method successfully.

	Best wishes,
	sergei