| Date Of Receipt: 13-MAY-1993 18:33:09.00
From: MINSRV::"[email protected]" "Joshua M. Friedman ULTRIX SDE"
To: [email protected]
CC: [email protected], [email protected]
Subj: fwd: revision comments getting rearranged?
Rima (et al),
Jim Campbell sent the attached question about rearrangement of headers
now in ode. Yesterday John Flanagan found this sort of case, but which
included branch numbers from a different rcs pool (our old mips pool)
in with branches from the current os pool. This added additional
confusion. In the attached diffs, the new header seems to have older
stuff (lower branch #s) closer to the top. ???
Attached below Jim's mail is the ptt history of a bug fix which you
just patched and which we have incorporated in our environment, which
is the cause (I assume) of this rearrangement. I can see the value
in cleaning up headers, and little by little files which have, in
some sense, been jumbled up, will get "fixed" and more orderly.
Jim's feeling on this was that files which already have history should
be left alone, since diffs are confusing and unexpected. He was
wondering if there was some way we could or should disable this feature
until it gets more discussion or concensus, since it presents major new
diffs to people.
Can you give us more information on exactly how things work now and
what the goal(s) were? Thanks. Your explanation in the attached ptt
report isn't detailed enough to really understand exactly what to
expect, although the scenarios presented are very explicit:
> a possible solution can be ordering and sorting all revisions log history
> revision in a ascendent order, with their correspondent comment.
>
> So in this way, we can keep track of all modifications done to the file,
> and eliminate the occurences of header conflict.
> the problem described above is being solved in DECode version 2.1.
> the merge routine called by bsubmit command, is being modified to eliminate
> any header conflicts that used to cause merge conflicts.
Maybe if you could provide an explanation (like patch release notes,
available as part of the ode_2.0_bug_fix sup collection) which we could
provide to our users ('usg') of what to expect, and how to appropriately
do merges with old and new header content, this would help us all.
Thanks very much.... --josh
--------
Return-Path: [email protected]
Received: by locore.zk3.dec.com (5.65/DEC-USSG-ZK3-ULTRIX-09/27/91);
id AA01648; Thu, 13 May 1993 17:06:05 -0400
Message-Id: <[email protected]>
To: [email protected]
Cc: [email protected], [email protected]
Subject: revision comments getting rearranged?
Date: Thu, 13 May 93 17:06:04 -0400
From: "Jim Campbell dtn: 381-0792" <[email protected]>
X-Mts: smtp
Attached is an ode 'problem' I don't understand.
I did a submit of kn7aa.c. I deleted a printf, added a revision
comment and submited it. A two line change.
I did a diff just now of the file I bci'ed (I keep copies of every
submit around to ensure I can recreate them if things go wrong)
and what is in the nightly and there is a significant difference
in the revision comments section.
The code portion is as I expected. (i.e. correct)
Attached is the diff. How did these comments get shuffled around?
It's quite disconcerting to do a diff of a two line change and get 200
lines that differ. This also happened to sched_prim.c.
Is there something I did to make this happen? It's bad when this happens,
since it will create a hugh amount of chaff when merges occur.
Regards, Jim...
7,52d6
< * Revision 1.1.7.8 1993/05/11 21:52:17 Jim_Campbell
< * Remove presto not present message during config.
< * [1993/05/11 21:48:31 Jim_Campbell]
< *
< * Revision 1.2.4.9 92/04/02 13:47:07 Peter_Mott
< * Define missing symbol PRM_DBG.
< * Include missing routine ka_ruby_check_todr_setup.
< * [92/04/02 13:46:23 Peter_Mott]
< *
< * Revision 1.2.4.8 92/04/01 12:38:26 Peter_Mott
< * Put in new readtodr and writetodr to use standard routines between
< * cobra, ruby, et. al.
< * [92/04/01 12:37:00 Peter_Mott]
< *
< * Revision 1.2.4.7 92/03/17 14:16:37 Jim_Campbell
< * First cut at OSFPAL (builds successfully). Fixed cfe warnings.
< * [92/03/17 14:10:21 Jim_Campbell]
< *
< * Revision 1.2.4.6 92/03/09 23:37:13 Jim_Campbell
< *
< * Presto tweeks
< * [92/03/09 22:12:05 Jim_Campbell]
< *
< * Revision 1.2.4.5 92/02/10 13:40:40 Jim_Campbell
< *
< * added latent presto support, fixed broken writetodr routine,
< * fixed up indentation
< * [92/02/10 13:21:10 Jim_Campbell]
< *
< * Revision 1.2.4.4 92/02/07 18:08:57 Jay_Estabrook
< * Alpha DSA merge
< * [92/02/07 18:04:19 Jay_Estabrook]
< *
< * Revision 1.2.4.3 92/02/05 17:54:51 Peter_Mott
< * removed superfluous copyright statement.
< * removed erroneous local declaration of yrtime in ka_ruby_writetodr.
< * corrected indentation - tab stops set to 8.
< * [92/02/05 17:34:21 Peter_Mott]
< *
< * Revision 1.2.4.2 92/02/05 14:34:33 Peter_Smith
< * Change names of time conversion routines.
< * [92/02/05 14:32:59 Peter_Smith]
< *
< * Revision 1.2 92/01/15 01:03:08 devbld_gsf
< * Baselevel alpha_bl002
< *
60c14
< *
---
> *
83,89d36
< * Revision 1.1.3.2 92/08/21 05:18:50 Peter_Mott
< * Add machine check parsing.
< *
< * Add clock month bias to match that used by OSF.
< *
< * Cleanup debug.
< *
184a132,262
> *
> * Revision 1.1.2.9 92/07/09 09:53:57 Randall_Brown
> * Cleanup of #ifdef OSFPAL
> * [92/07/08 08:40:29 Randall_Brown]
> *
> * Revision 1.1.2.8 92/06/23 16:41:18 Jim_Campbell
> * Missed BL7 mirror: Initialize *system_intr_cnts_type_transl
> * [92/06/23 16:07:55 Jim_Campbell]
> *
> * Revision 1.1.2.7 92/06/03 20:33:43 Joseph_Amato
> * badaddr interface changes and 1st pass of fbus
> * [92/06/03 10:33:55 Joseph_Amato]
> *
> * Revision 1.1.2.6 92/05/27 19:21:11 Jim_Campbell
> * Just changed the boot message to VAX7000
> * [92/05/27 19:05:37 Jim_Campbell]
> *
> * Revision 1.1.2.5 92/04/24 15:36:51 Anton_Verhulst
> * Add initialization of global pointer system_bus.
> * System_bus is global pointer used by loadable code when walking
> * the hardware topology tree. It is extern'd via devdriver.h.
> * [92/04/24 15:34:44 Anton_Verhulst]
> *
> * Revision 1.1.2.4 92/04/20 15:36:06 Jim_Campbell
> * Silver BL6 merge: modified presto interface
> * [92/04/20 15:35:21 Jim_Campbell]
> *
> * Revision 1.1.2.3 92/04/10 13:22:21 Stuart_Hollander
> * errlog.h is now in dec/binlog
> * [92/04/09 14:46:30 Stuart_Hollander]
> *
> * Revision 1.1.2.2 92/04/03 12:37:43 Stuart_Hollander
> * scb.h is now in arch/alpha
> * ka_ruby.h now in hal
> * Moved file from arch/alpha to hal
> * [92/04/02 19:08:49 Stuart_Hollander]
> *
> * Initial version. File copied from TIN-based Alpha pool.
> * [91/12/06 16:04:51 David_Snow]
> *
> * Revision 1.1.2.8 92/01/14 13:19:54 Peter_Mott
> * fix up todrread and write routines.
> * [92/01/14 12:47:10 Peter_Mott]
> *
> * Revision 1.1.2.7 92/01/02 11:38:44 Al_Delorey
> * Merged my changes with prior version
> * [92/01/02 11:36:40 Al_Delorey]
> *
> * Fixed a comment (to test bmerge)
> * [92/01/02 11:32:35 Al_Delorey]
> *
> * No real source change, just a test of ODE-II bmerge
> * [92/01/02 11:15:30 Al_Delorey]
> *
> * Revision 1.1.2.6 92/01/02 11:10:12 Jim_Campbell
> * Checked out to test bmerge functionality with Al...
> * [92/01/02 11:09:27 Jim_Campbell]
> *
> * Revision 1.1.2.5 91/12/30 18:49:49 Jim_Campbell
> * Commented out debug messages, cleaned out some unused (adu) code
> * [91/12/30 18:39:47 Jim_Campbell]
> *
> * Revision 1.1.2.4 91/12/11 18:26:02 Al_Delorey
> * scb.h moved to hal
> * [91/12/11 18:24:17 Al_Delorey]
> *
> * Revision 1.1.2.3 91/12/07 18:16:17 Al_Delorey
> * fixed include paths for pool reorg
> * [91/12/07 17:25:51 Al_Delorey]
> *
> * Revision 1.1.2.2 91/12/06 17:54:11 David_Snow
> * "Initial version. File copied from TIN-based Alpha pool."
> *
> * Revision 1.1.3.2 92/08/21 05:18:50 Peter_Mott
> * Add machine check parsing.
> *
> * Add clock month bias to match that used by OSF.
> *
> * Cleanup debug.
> *
> * Revision 1.2.4.9 92/04/02 13:47:07 Peter_Mott
> * Define missing symbol PRM_DBG.
> * Include missing routine ka_ruby_check_todr_setup.
> * [92/04/02 13:46:23 Peter_Mott]
> *
> * Revision 1.2.4.8 92/04/01 12:38:26 Peter_Mott
> * Put in new readtodr and writetodr to use standard routines between
> * cobra, ruby, et. al.
> * [92/04/01 12:37:00 Peter_Mott]
> *
> * Revision 1.2.4.7 92/03/17 14:16:37 Jim_Campbell
> * First cut at OSFPAL (builds successfully). Fixed cfe warnings.
> * [92/03/17 14:10:21 Jim_Campbell]
> *
> * Revision 1.2.4.6 92/03/09 23:37:13 Jim_Campbell
> *
> * Presto tweeks
> * [92/03/09 22:12:05 Jim_Campbell]
> *
> * Revision 1.2.4.5 92/02/10 13:40:40 Jim_Campbell
> *
> * added latent presto support, fixed broken writetodr routine,
> * fixed up indentation
> * [92/02/10 13:21:10 Jim_Campbell]
> *
> * Revision 1.2.4.4 92/02/07 18:08:57 Jay_Estabrook
> * Alpha DSA merge
> * [92/02/07 18:04:19 Jay_Estabrook]
> *
> * Revision 1.2.4.3 92/02/05 17:54:51 Peter_Mott
> * removed superfluous copyright statement.
> * removed erroneous local declaration of yrtime in ka_ruby_writetodr.
> * corrected indentation - tab stops set to 8.
> * [92/02/05 17:34:21 Peter_Mott]
> *
> * Revision 1.2.4.2 92/02/05 14:34:33 Peter_Smith
> * Change names of time conversion routines.
> * [92/02/05 14:32:59 Peter_Smith]
> *
> * Revision 1.2.4.3 92/02/05 17:54:51 Peter_Mott
> * removed superfluous copyright statement.
> * removed erroneous local declaration of yrtime in ka_ruby_writetodr.
> * corrected indentation - tab stops set to 8.
> * [92/02/05 17:34:21 Peter_Mott]
> *
> * Revision 1.2.4.2 92/02/05 14:34:33 Peter_Smith
> * Change names of time conversion routines.
> * [92/02/05 14:32:59 Peter_Smith]
> *
> * Revision 1.2 92/01/15 01:03:08 devbld_gsf
> * Baselevel alpha_bl002
------- Forwarded Message
Return-Path: [email protected]
Received: by wasted.zk3.dec.com (5.65/DEC-USSG-ZK3-ULTRIX-09/27/91);
id AA04611; Fri, 7 May 1993 13:51:15 -0400
Date: Fri, 7 May 1993 13:51:14 -0400
Message-Id: <[email protected]>
From: [email protected] (07-May-1993 1051)
To: [email protected]
Subject: Results from: history ODE-00122
Action Problem Last
Number Status Status Pri Owner PRODUCT Flags Age Updated
====== ====== ====== === ===== ======= ===== === =======
ODE-00122 CL CL 3 MANSOUR ODE 143 6-MAY-1993
DEC - Merge Conflicts Caused By Headers Conflicts
Submitted by: RIMA MANSOUR of ODE in USA
(548-8709 )
Mail address: FUNGUS::MANSOUR
Answer code: FN
Fixed in version 2.1
Last accessed on: 6-MAY-1993 09:46: Number of days open: 143
(RC: 28.9 AK:113.8 SB: 0.0 EL: 0.0 CL: 0.0)
(UN:142.7 DE: 0.0 RE: 0.0 ER: 0.0 KN: 0.0 ST: 0.0 CP: 0.0 TR: 0.0)
Problem first entered on 14-DEC-1992
PRODUCT: ODE 2.0
OS HARDWARE: ULTRIX/RISC 4.2
COMPONENT: BSUBMIT 2.0
OTHER:
Hardware: RISC System device:
Memory:
Abstract: Merge Conflicts Caused By Headers Conflicts
Customer company: DEC
[This update was sent from MOLD::"[email protected]" on 14-DEC-1992 17:13
[ODE responsible for next action, Problem is undefined]
Mail this report to: [email protected]
Note: ALL CAPS=Mandatory field
Problem Submission Form Mon Dec 14 17:05:34 PST 1992
Required Information
====================
YOUR NAME: Rima Mansour
Your Email address: [email protected]
YOUR PHONE NUMBER: 548-8709
Your fax number: DTN 548-8890
Your company name: DEC
Your mailstop: ZSO
YOUR ORGANIZATION'S NAME: DECwest
YOUR COST CENTER: 35W
Your street address: Digital Equipment Corporation
DECwest Engineering
14475 N.E. 24th St.
Bellevue, WA 98007 USA
- --------------------------------------
CUSTOMER'S COMPANY NAME: DEC
CUSTOMER COUNTRY: USA
- --------------------------------------
PRODUCT: ode
Product version (optional): V2.0
OS HARDWARE: ULTRIX/RISC
OS Hardware version: 0
Workstation soft version (optional): V4.2
COMPONENT: bsubmit
Component version (optional): ode2.2b000:V-1.157:Prod-ver--V2.0
Other (optional):
OTHER Version (optional):
SYSTEM WHERE PROBLEM OCCURRED: rima.zso.dec.com
CPU type: RISC
Display type: ? display of type=
Memory size:
System disk:
Other hardware configuration information:
Other software configuration information:
ULTRIX V4.2 (Rev. 96) System #1: Wed Nov 13 16:05:24 PST 1991
UWS V4.2 (Rev. 272)
- --------------------------------------
PROBLEM ABSTRACT (80 characters or less):
Merge Conflicts Caused By Headers Conflicts
PROBLEM PRIORITY (1-5, 1 being most critical): 3
CAN THE CUSTOMER REPRODUCE THE PROBLEM [Y/N]: Y
CAN YOU REPRODUCE THE PROBLEM [Y/N]: Y
PROBLEM STATEMENT:
=================
scenario 1:
- -------------
PRE:
- ----
REV(submit_tree)(<filename>): defined
REV(sharedsb)(<filename>): defined
------------- | |
| submit_tree | | |-----------------
------------- | | 1.2.3: private branch
/\ | |-----------------
|| | T |
|| | R |-----------------
----- | U | 1.2.2: submit tree branch
| SB1 | | N |-----------------
----- | K |
| |-----------------
1) bco <filename> | 1.2 | 1.2.1: shared sandbox bran
ch
2) bci <filename> | |-----------------
3) bsubmit -noauto_out <filename>
4) resb <shared_sandbox>
5) bsubmit <filename>
Initially, file(A) has been submitted to both the submit tree and the
shared sandbox.
After step 1), log history of file(A) contains revision:
1.2 (initial rev),
1.2.2.2 (first submission to the submit tree),
1.2.3.1 (private branch rev),
After step 3), log history of file(A) contains revisions:
1.2 (initial rev),
1.2.2.2 (first submission to the submit tree),
1.2.3.2 (private branch rev after bci ),
Since we choose -noauto_out, nothing changes after step 4) .
At step 5), merge conflict are detected due to the conflict of log history
revisions and comments, between my private branch and the shared sandbox
branch :
shared sandbox branch:
----------------------
1.2 (initial rev)
1.2.1.2 (first submit rev to shared sandbox) <------------------
|
my private branch: |
------------------ Conflict
in file revision
1.2 (initial rev), |
1.2.2.2 (first submission to the submit tree), |
1.2.3.2 (private branch rev after bci ), <------------------|
scenario 2:
- -----------
-------------
| submit_tree |
-------------
/\
||
||
-----
| SB1 |
-----
1) bco <filename>
2) bci <filename>
3) bsubmit -noauto_out <filename>
4) resb sharedsb
5) bmerge -r"$default_set;<>" <filename>
6) bci ...
7) bsubmit <filename>
In scenario 2, the same merge conflicts are detected at step 5), caused by the
same header conflict discussed above.
I would like to note that the same will happen, if we reverse the
order of submitting to submit tree and shared sandbox.
/Rima
Instructions to reproduce the problem:
======================================
- --------------------------------------
<<<<<<<<<<<<<<<<<<<<<<<PTT UNIT SEPARATION>>>>>>>>>>>>>>>>>>>>>>
[This update was sent from PETERSON on 14-DEC-1992 17:22]
[ODE responsible for next action, Problem is undefined]
[This update was NOT sent via mail or to any gateway/bridge]
Problem has been reassigned to RIMA MANSOUR
<<<<<<<<<<<<<<<<<<<<<<<PTT UNIT SEPARATION>>>>>>>>>>>>>>>>>>>>>>
[This update was sent from RIMA::mansour on 15-DEC-1992 15:14]
[ODE responsible for next action, Problem is undefined]
Hi,
a possible solution can be ordering and sorting all revisions log history
revision in a ascendent order, with their correspondent comment.
So in this way, we can keep track of all modifications done to the file,
and eliminate the occurences of header conflict.
/Rima
<<<<<<<<<<<<<<<<<<<<<<<PTT UNIT SEPARATION>>>>>>>>>>>>>>>>>>>>>>
[This update was sent from MANSOUR on 6-MAY-1993 09:44]
[ODE responsible for next action, Problem is undefined]
<<<<<<<<<<<<<<<<<<<<<<<PTT UNIT SEPARATION>>>>>>>>>>>>>>>>>>>>>>
[This update was sent from MANSOUR on 6-MAY-1993 09:48]
[The problem is closed]
the problem described above is being solved in DECode version 2.1.
the merge routine called by bsubmit command, is being modified to eliminate
any header conflicts that used to cause merge conflicts.
thanks,
/Rima
------- End of Forwarded Message
|