Conference smurf::buildhelp

111.0. "no data yet re: data on bsubmit problem" by SMURF::FILTER (Automatic Posting Software - mail to flume::puck) Mon Jun 07 1993 17:43

Date Of Receipt: 	 4-JUN-1993 00:22:33.46
From: 	WASTED::jmf "Joshua M. Friedman ULTRIX SDE  04-Jun-1993 0021"
To: 	hoskins@wasted:zko.dec
CC: 	jproj@wasted:zko.dec, reng@wasted:zko.dec, heather@wasted:zko.dec,
	rtm@wasted:zko.dec, odehelp@wasted:zko.dec
Subj: 	no data yet re: data on bsubmit problem

Tim, there have been no ptt reports on ODE entered regarding bsubmit
losing submit content or failing to recognize merge conflicts.

I sent you mail 2 days ago (attached) on how to enter a bug report
against bsubmit.  If in fact there is really a problem, it must be
reported by someone who can provide the context information with what
exactly was being done and what exactly happened.  The gen-ptt command
should be run from a sandbox on a system which experienced the problem.

A bug of this sort certainly is a P1 and should not just be talked
about, but needs to be reported, with as much specific information as
possible.  The resources you referred to below are already assigned and
working (in DECwest) on supporting ODE.

re:
>     2. bsubmit indicating no merge action was required by the
>             submittor, and yet the resultant file in the pool being
>             "not what I bsubmitted"
>             - 3 (known!) files
>     1)  Recommendation: Assign resources to investigate why, and
>         fix, the problem with bsubmit failing to recognize merge
>         conflicts.

thank you...	-josh


--------
Return-Path: jmf
Message-Id: <[email protected]>
To: hoskins
Cc: odehelp, jproj, tappan
Subject: re: data on bsubmit problem
Date: Wed, 02 Jun 93 12:09:20 +28716
From: "Joshua M. Friedman, OSF/UNIX SDE 381-1548" <jmf>
X-Mts: smtp

Tim, please use the supported mechanism for reporting bugs in ODE, rather
than sending mail to individuals or to the project team.

All ode users are capable of submitting bug reports, and should, if there
are any problems in the tools.  

>From within your sandbox workon session which had the problem, type the
command:
	gen-ptt

This will, the first time, prompt you for personal data which is stored for
future reference.  It will then prompt you on the component you're reporting
(ode) and the particular area (bsubmit).  It will then gather information 
from your sandbox, and then put you in your editor to complete the form.

Please include the 1-line abstract (required), and as much information
about the problem and how to reproduce it, if possible, as you can
provide in the appropriate sections of the form.  After you exit the
editor, you'll be prompted to mail or exit.  If your machine can send
mail, take that (default) option, else exit and copy the ptt_temp file
to another system and mail it to decwet::ptt_ode with subject "problem
submission"

Thanks for your help...		-josh


------- Forwarded Message

Return-Path: [email protected]
Received: by flume.zk3.dec.com (5.65/DEC-USSG-ZK3-ULTRIX-09/27/91);
	id AA28209; Tue, 1 Jun 1993 18:12:02 -0400
Received: from localhost by maceo.zk3.dec.com (5.65/Ultrix-4.3)
	id AA18089; Tue, 1 Jun 1993 18:11:41 -0400
Message-Id: <[email protected]>
To: [email protected]
Cc: [email protected], [email protected]
Subject: data on bsubmit problem
Date: Tue, 01 Jun 93 18:11:40 EDT
From: [email protected]

Several people have reported a problem with bsubmit.  We need the ode team to
tell us how they want to work this.  Do you want a qar entered?  In what
database?

thanks,
sarah


- ------- Forwarded Message

Delivery-Date: Tue, 01 Jun 93 18:09:17 -0400
Return-Path: hoskins
Received: by flume.zk3.dec.com (5.65/DEC-USSG-ZK3-ULTRIX-09/27/91);
	id AA28118; Tue, 1 Jun 1993 18:09:13 -0400
Received: by ruddy.zk3.dec.com; id AA24952; Tue, 1 Jun 1993 18:09:13 -0400
Date: Tue, 1 Jun 1993 18:09:13 -0400
From: Tim Hoskins AUEG <hoskins>
Message-Id: <[email protected]>
To: [email protected]
Subject: some data on bsubmit problems


    this was provided by Ron Menner.

>>    2. bsubmit indicating no merge action was required by the
>>          submittor, and yet the resultant file in the pool being 
>>          "not what I bsubmitted"
>>          - 3 (known!) files

This happened to me also.  For the Streams submit we were basicly
doing a replace since we had already merged our files the day before.
At the bmerge prompt for edit, "rco" was being entered to overwrite
what was currently in the pool.  But on one occasion a file showed
up as requiring merge action but instead of asking the bmerge edit
question it gave the bmerge "ok" prompt.  Since muliple files were
being submitted at once and the bmerge "ok" prompt does not contain
the file name ... i mistakenly thought it was prompting again for
the same file that i already had responded "ok" to.  Once this file
was submitted it showed up as no merge conflicts to a subsequent
submit.


- ------- End of Forwarded Message


------- End of Forwarded Message