Conference smurf::buildhelp

1941.0. "Problems with bsubmitting same file to two pools" by AOSG::FILTER (Automatic Posting Software - mail to flume::puck) Wed Nov 08 1995 13:43

Date Of Receipt: 	 8-NOV-1995 13:03:38.88
From: 	SMURF::GURU::dike "Jeff Dike USG  08-Nov-1995 1301"
To: 	odehelp@dec:.zko.guru
CC: 	
Subj: 	Problems with bsubmitting same file to two pools

I am submitting a file to two pools from two sandboxes.  The first submit was 
fine.  When I did the second, bstat -all says:
[ ./kernel/nfs/nfs_vnodeops.c ]
[ There is no branch revison for set Jeff_Dike_aju. ]

and bsubmit fails.

This has happened every time I've had to bsubmit the same file to different 
pools at the same time.  The previous times, I have bcs -o -u the second file, 
redid the changes, and submitted.  That resulted in a revision crossing pools 
and breaking a build.  I was told that that was because I told the first bsubmit 
to outdate the file instead of letting it decide for itself what to do.  So, I 
just took bsubmit's defaults this time, and the same thing is about to happen.

So, the short version of what I've done so far is:
workon to 3.2 sandbox
bstat -all for a sanity check
bsubmit ./kernel/nfs/nfs_vnodeops.c
exit
workon to 3.2C sandbox
bstat -all, it gives the message above

I'd like to know what I should do now and what if anything I did wrong.  My DTN 
is 381-2265.

The full log of what I did is attached below.

				Thanks, Jeff


useg98.zk3.dec.com 303> kinit
Kerberos Initialization
Kerberos name: Jeff_Dike
Password: 
useg98.zk3.dec.com 304> workon aju -sb v32
ksh
cd'ing to sandbox source directory: /usr/sb/v32/src.
starting new shell: /bin/csh.
useg98.zk3.dec.com 198> >                                                      
useg98.zk3.dec.com 198> bstat -all

[ ./kernel/nfs/nfs_vnodeops.c ]
version 1.1.87.2 selected
useg98.zk3.dec.com 199> more ../link/logs/sr*/*/188

... I read my srequest...

useg98.zk3.dec.com 200> bsubmit -all
Enter the defect number this submission applies to: v32supportos-188-dike


Outdate files if successful submission? [Y]es, [N]o, [Q]uery later]: [Yes] 
The following file(s) will require user interaction during the merge step:
  ./kernel/nfs/nfs_vnodeops.c

Please make a choice from the following list of options:
merge    - Submit all files at this time;
           you will perform required merges now.
no_merge - Submit only files that do not require merging;
           skip all other files.
exit     - Exit bsubmit now, terminating the submission.

Your choice (merge, no_merge, exit): [merge] 
Warning: 2 overlaps during merge of ./kernel/nfs/nfs_vnodeops.c.

  -- The working file corresponding to './kernel/nfs/nfs_vnodeops.c', 
  -- contains, merge conflict markers,of the form, 
  -- '<<<<<<<',  '=======' or '>>>>>>>'. 
  -- Please edit it, to resolve all merge  
  -- conflicts, and remove the conflict markers.

'./kernel/nfs/nfs_vnodeops.c' NOT merged - choose a merge option from the 
following list:

visual   -  Re-do the merge in visual mode on DISPLAY useg98:0.
            Only select this option if useg98:0 is a valid value for DISPLAY.
            The visual option will be in effect for this file only.

novisual    -  Re-do the merge in non-visual mode.

rco      -  Ignore the result of the previous merge action.
            Take the latest copy, found on the current private
            branch,'Jeff_Dike_aju'. Your work will overwrite
            version 'V32SUPPORTOS'.

co       -  Ignore the result of the previous merge action.
            Put back version 'V32SUPPORTOS' as is, in the 
            resulting file.

Choose next merge action on ./kernel/nfs/nfs_vnodeops.c
Abort, edit, [r]diff, r[co], help  [edit]  

Choose next merge action on ./kernel/nfs/nfs_vnodeops.c
Abort, ok, edit, novisual, visual, [r]co, help  [rdiff]  
===================================================================
RCS file: ./kernel/nfs/nfs_vnodeops.c,v
retrieving revision 1.1.87.2
13a14,20
>  * Revision 1.1.82.2  1995/10/05  13:59:31  Jeff_Dike
>  *    Fix last fix.  Moved the new code to the correct place.
>  *    [1995/09/20  13:22:54  Jeff_Dike]
>  *
>  *    Backport Aju's fix for QAR 33924.
>  *    [1995/09/20  13:05:07  Jeff_Dike]
>  *
diff -r1.1.87.2 OdeSrvrTmpJeff_Dike015011/nfs_vnodeops.c

Choose next merge action on ./kernel/nfs/nfs_vnodeops.c
Abort, ok, edit, novisual, visual, [r]co, help  [diff]  
===================================================================
RCS file: ./kernel/nfs/nfs_vnodeops.c,v
retrieving revision 1.1.82.2
6a7,13
>  * Revision 1.1.87.2  1995/11/06  14:09:24  Jeff_Dike
>  *    Fix call to ubc_invalidate in nfs_strategy
>  *
>  * Revision 1.1.84.2  1995/10/18  16:52:17  Jeff_Dike
>  *    Backport Aju's fix for QAR 33924.
>  *    [1995/10/18  16:51:03  Jeff_Dike]
>  * 
13a21,27
>  * Revision 1.1.73.2  1995/01/20  00:05:07  Paula_Long
>  *    Merged in:
>  *       Revision 1.1.68.2  1994/11/08  17:43:26  Andrew_Duane
>  *       Removed #include <mach_xp.h>
>  *       [1994/09/21  13:37:00  Andrew_Duane]
>  *    [1995/01/19  19:48:37  Paula_Long]
>  * 
502c516
< #pragma ident "@(#)$RCSfile: nfs_vnodeops.c,v $ $Revision: 1.1.82.2 $ (DEC) 
$Date: 1995/10/05 13:59:31 $"
---
> #pragma ident "@(#)$RCSfile: nfs_vnodeops.c,v $ $Revision: 1.1.87.2 $ (DEC) 
$Date: 1995/11/06 14:09:24 $"
529d542
< #include <mach_xp.h>
2337c2350
<                         ubc_invalidate(rtov(rp)->v_object,
---
>                         ubc_invalidate(rtov(rp),
diff -r1.1.82.2 OdeSrvrTmpJeff_Dike013716/nfs_vnodeops.c

Choose next merge action on ./kernel/nfs/nfs_vnodeops.c
Abort, ok, edit, novisual, visual, [r]co, help  [ok]  
[ ./kernel/nfs/nfs_vnodeops.c checked in onto branch 1.1.82 ]
[ ./kernel/nfs/nfs_vnodeops.c Rev 1.1.82.3 checked out ]
[ ./kernel/nfs/nfs_vnodeops.c outdated revisions in set Jeff_Dike_aju ]

Submission completed successfully.
useg98.zk3.dec.com 201> 
% useg98.zk3.dec.com 305> more /usr/sb/v32c/src/.BCSs*

... I see which set I need to workon to ...

useg98.zk3.dec.com 306> workon aju -sb v32c
ksh
cd'ing to sandbox source directory: /usr/sb/v32c/src.
starting new shell: /bin/csh.
% useg98.zk3.dec.com 201> bstat -all

[ ./kernel/nfs/nfs_vnodeops.c ]
[ There is no branch revison for set Jeff_Dike_aju. ]
useg98.zk3.dec.com 202> bsubmit -all
Enter the defect number this submission applies to: v32csupportos-72-dike


Outdate files if successful submission? [Y]es, [N]o, [Q]uery later]: [Yes] 

*** No user interaction will be required during the merge step. ***


*** VALIDATION FAILURE ***

./kernel/nfs/nfs_vnodeops.c -- not in set.

Consult the bsubmit reference page for suggested corrective actions.

Please take appropriate steps and run bsubmit again.
- No work has been done for this submission.
- No files have been changed in any way.
- The files in this submission are not held.
- The use of the -resub option is not required and will not be recognized.

Date Of Receipt: 	 8-NOV-1995 13:46:43.55
From: 	SMURF::FLUME::johnf "John Flanagan USG Test Johnf Tools Group  08-Nov-1995 1344"
To: 	dike@DEC:.zko.flume
CC: 	odehelp@DEC:.zko.flume
Subj: 	Re: Problems with bsubmitting same file to two pools

The key to making dual submitting work is to NOT outdate the file between
submits.  Make sure that if you have -auto_out set that you overide it
with noauto_out so that you local branch doesn't get outdated between submits.
Then, you can resb to the new tree [you'll need to exit and re-enter after
this] and then bsubmit again.

John


 ______________________________________________________________________

 John Flanagan	 		enet:    [email protected]	
 MS: ZKO3-3/W20			decnet:  flume::johnf
 USG Release Engineering		 (603) 881-1719
 110 Spitbrook Road 			 (DTN) 381-1719
 Nashua, NH  
 ______________________________________________________________________

Date Of Receipt: 	 8-NOV-1995 14:14:32.56
From: 	SMURF::GURU::dike "Jeff Dike USG  08-Nov-1995 1412"
To: 	odehelp@dec:.zko.guru
CC: 	
Subj: 	Problems with bsubmitting same file to two pools

To add a detail or two to my previous message, I am making a similar fix to the 
same file in two different releases.  The file names are the same, but the 
contents have changed between releases.  Thus, I am doing each file from a 
different sandbox.  It turns out that I should have told the first bsubmit not 
to outdate the file.  The question is, what do I do given that I have?

				Thanks, Jeff