This file contiains ODE 2.3.4 CRs only. There is a summary with short
descriptions followed by the full CRs.

===============================================================================
ODE 2.3.4 CRs
===============================================================================

Summary:

CRnum S P Short_Description
 1088 A 0 resb core dumping on hp700_hpux
 1084 A 0 sadmin -edit log fails
 1083 B 0 bmerge overzealous
 1070 C 3 sbinfo core dumps when in wrong sandbox
 1066 C 0 bci usage message needs updating
 1064 C 3 supfilsrv is missing from 2.3.4-beta
 1063 B 2 sup 2.3.4-beta breaks the -d switch
 1062 C 2 bco does not check permissions
 1061 C 0 bco -undo error ?
 1060 B 1 skipto() should handle negative chars
 1056 C 3 separate sup programs
 1054 C 0 mksb creating link and tools dir in non ode build
 1052 C 0 bco -p changes permissions on files
 1051 A 0 supscan coredump
 1049 D 0 remove build warnings and Errors
 1041 B 0 copyright and history documentation required
 1040 B 0 ode not using subproject copyrights file
 1034 A 0 regression: bsubmit -resub broken
 1030 A 0 ci called by bsubmit complains about improper revi
 1029 A 0 update release notes for 2.3.4
 1027 C 0 convert 2.3.4 build into full build
 1025 B 1 sadmin -edit log scrambles permissions
 1023 B 1 bsubmit does not allow user to abort if merge requ
 1020 B 0 can not find ancestry when both branches have trun
 1014 C 2 Years characters should include "-"
 1013 B 0 merging with bsubmit deosn't work on at386_sinix
 1005 C 1 bmerge core dumps after a complete bsubmit!
 1004 C 1 mklinks ignores -sb switch
 1003 A 0 bcreate -undo should not remove files
 1002 C 1 Regression: bcreate -undo overzealous
 1000 A 2 ODE segvs if ancestor cannot be found
  990 C 3 bco -read gives weird error message if file doesn'
  988 C 1 resb complains about backing project line with no
  983 B 1 BCSSET no longer set in env
  979 D 4 mksb complains that build is not upgraded if it do
  977 C 2 bci core dumps on 0-length files
  976 A 2 bmerge core dumps
  975 C 1 bmerge -common acts differently than bmerge
  972 B 1 bco -p should ignore rw perm of file
  971 C 1 resb should complain about invalid backing build
  968 E 1 bsubmit of defunct files leaves 2 #srvtmp* files b
  967 B 1 bcreate -undo does nothing with BIN and NONE files
  966 A 1 bstat dumps core.
  964 D 1 bco -p should not print file name
  963 D 1 bsubmit accepts -changed switch
  962 A 1 mklinks is broken in ODE 2.3.3
  961 A 1 Very scary bsubmit message
  957 C 2 bdiff output contains kruft
  956 B 1 bdiff displays garbage rev number
  955 E 4 bdiff should print branch labels
  954 B 1 bdiff assumptions
  952 A 1 resb dumps core.
  951 B 1 bsubmit of leaderless file from backing build fail
  950 B 1 bsubmit ignores -rc option
  949 B 2 wrong status & confusing bco message
  942 B 1 ODE needs VERROR for ui_print()
  938 C 3 bci of file with garbage comment leader hic-ups 'o
  934 A 0 bco warning is really an error
  932 A 0 bco silently overwrites writeable files
  929 A 0 mklinks removes a character in pathname when path
  928 A 0 regression: bsubmit gives unexpected eof if merge
  925 B 1 bmerge should complain if rev not found
  923 E 1 bsubmit should not print full name when -auto and/
  922 D 1 bco -undo gives no info if no user branches exist
  921 C 1 bcreate -undo of bci'd file gives internal error
  920 C 1 bcreating already bcreated files prints misleading
  919 B 1 bci fails & odexm locks sandbox
  918 D 1 bmerge updates files unnecessarily
  915 D 1 bdiff doesn't print file names
  914 B 1 bci no longer printing file names if -auto is used
  908 B 2 mksb 2.3.3 dumps core on alpha
  906 A 0 rcs 5.6 still has BIN problems!!
  904 C 2 mklinks does not use mkdir -p?
  902 A 3 bcreate dumps core if it doesn't like copyrights f
  900 D 3 bco error message garbled
  899 C 1 bsubmit -info does update when merge is required
  897 C 3 bci -all is not informative
  896 C 3 logdiff not abbreviated
  895 C 2 ./ interpreted by ODE as /
  888 C 3 resb considered harmful
  886 E 1 remove unecessary printf of common ancestor
  884 E 0 merging still prints rcs info
  883 A 2 bdelta not built for ODE2.3
  882 B 0 bstat -a fails when ancestor is not direct
  880 E 0 bcreate -undo still prints rcs info
  876 C 1 mklinks od's on "." and "/"
  875 E 4 _LOG_ file left in sandbox tmp dir
  871 B 0 bcreate does not always set expansion mode correct
  867 B 1 bsubmit too picky during validation
  865 A 0 separate copyright/history broken
  860 A 0 bootstrap build broken on at386_sinix
  857 B 1 update test suite
  856 C 1 man page for odexm
  852 A 0 bmerge -common segvs
  849 C 3 "mksb -back /project/osc/build/osc1.3 foo" core du
  848 A 1 bcreate does not special case BIN
  847 C 4 Speedup mklinks for Motif Group
  845 B 1 document exclusive file locking
  844 B 1 mismatched comparison of ancestry info
  843 B 1 Include Buildconf.local
  841 B 1 map file name does not print on error
  840 B 1 ODE should not use temporary files in user's src d
  839 D 1 edits during bci go into rcs file but not into san
  838 B 1 RAT admin with/for external providers less secure
  837 D 1 bsubmit creates extra log files
  836 C 3 snapshot file now overloaded
  835 C 3 aliasing of commands in .sandboxrc does not work
  834 A 3 2.3 make and makefiles inadequately tested
  833 A 4 set creation/info no longer local to build server
  827 B 2 bci -xlog deleted, no equivalent function
  824 B 1 Unexpected EOF in bci
  819 C 2 bci xtract fails to extract log
  818 C 3 workon requires -setdir instead of optionally
  815 C 3 bci ignores auto when given entered at bci's promp
  814 C 3 supscan & supfilesrv are missing from ode 2.3
  812 C 3 Remove sindex from man/{man3,cat3}/Makefile
  807 D 2 bsubmit should do a bit less when interrupted duri
  806 C 3 sbinfo should indicate when there is no default sa
  804 C 3 document sb.conf
  801 C 3 document locking a sandbox
  800 C 3 bootstrap.sh needs some updating
  794 C 3 document new COPYRIGHT NOTICE handling
  793 B 3 supfilesrv doesn't handle EINTR when figuring out
  790 C 3 bcreate -undo says nothing if it fails
  788 C 3 configurable odexm.conf location
  785 C 3 salloc referred to in man pages
  773 B 1 user's set can not be same as backing build set
  772 C 3 bcreate -undo fails if no revisions in file
  763 C 1 File is locked message not always getting back to
  756 A 0 version numbers are incorrectly increased
  747 C 1 user selectable ancestor for bco
  736 C 3 mklinks confused by link in sandbox path
  679 C 3 bsubmit exits quietly if ancestry info is garbled.
  667 C 3 Corrections in documentation.
  663 B 2 ODE 2.3 needs 'bco -undo' back.
  657 D 3 mklinks confused by sandbox setup
  654 C 3 'make' should not depend on "/usr/bin/sh".
  629 C 1 errors in ODE User's Guide
  628 C 1 make manpage missing .tryinclude
  623 C 3 man pages need updating
  599 C 3 bcreate ALWAYS queries user when non-standard comm
  540 C 3 mklinks doesn't work on first level directory in s
  234 C 1 No "bco -p" switch
  108 C 1 -query does dir by dir not file by file
   70 C 1 mklinks -copy doesn't preserve execute permission

CR Number                     : 1088
Short Description             : resb core dumping on hp700_hpux
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : marty (Marty Lynch)
Reported by Company           : osf
Interest List CC              : mckeen@osf.org
Reported Date                 : 3/8/94
Found in Baseline             : 2.3.3
Found Date                    : 3/8/94
Severity                      : A
Priority                      : 0
Status                        : fix
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : lib/libode/sbdata.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[marty 3/8/94 public]
The routine sb_conf_std in sbdata.c is dereferencing through a NULL
pointer.  THis is effecting "resb" on hp's

[marty 3/8/94 public]
Fixed!


CR Number                     : 1084
Short Description             : sadmin -edit log fails
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 3/3/94
Found in Baseline             : 2.3.3
Found Date                    : 3/3/94
Severity                      : A
Priority                      : 0
Status                        : fix
Duplicate Of                  : 
Fix By Baseline               : 2.3.4,2.3.5
Fixed In Baseline             : 2.3.4,2.3.5
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 3/3/94 public]

sadmin -edit log produces:

>> FATAL ERROR in admincopy:
>> ERROR: could not open file: ode2.3_server_base/bsubmit.hold, to copy to.
>> FATAL ERROR in sadmin:
        could not copy edited file, /usr/users/damon/sandboxes/ode235/tmp/bsubmit.hold,
 back to build.

The edits to use the sandbox tmp dir inadvertently switched some file names.


CR Number                     : 1083
Short Description             : bmerge overzealous
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 3/3/94
Found in Baseline             : 2.3.4
Found Date                    : 3/3/94
Severity                      : B
Priority                      : 0
Status                        : fix
Duplicate Of                  : 
Fix By Baseline               : 2.3.4,2.3.5
Fixed In Baseline             : 2.3.4,2.3.5
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 3/3/94 public]
bmerge contains a routine called 'verify_merge_rev_list()' which
checks the value of has_merge_branch. If this is FALSE it claims that this
is an error. This is not an error. 'has_merge_branch' simply indicates
whether or not there is already a branch for the default set.


CR Number                     : 1070
Short Description             : sbinfo core dumps when in wrong sandbox
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : meissner (Michael Meissner)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 3/2/94
Found in Baseline             : 2.3.3
Found Date                    : 3/2/94
Severity                      : C
Priority                      : 3
Status                        : open
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 
Affected File(s)              : 
Responsible Engr.             : 
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[meissner 3/2/94 public]
If you are in a workon subshell, cd to a different sandbox, and then do a
sbinfo, the sbinfo command will core dump.  This is true for 2.3.3 and
2.3.4-beta.


CR Number                     : 1066
Short Description             : bci usage message needs updating
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 2/28/94
Found in Baseline             : 2.3.3
Found Date                    : 2/28/94
Severity                      : C
Priority                      : 0
Status                        : fix
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 2/28/94 public]

-xlog should be -x.


CR Number                     : 1064
Short Description             : supfilsrv is missing from 2.3.4-beta
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : meissner (Michael Meissner)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 2/24/94
Found in Baseline             : 2.3.4
Found Date                    : 2/24/94
Severity                      : C
Priority                      : 3
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[meissner 2/24/94 public]
Supfilsrv (the server sup connects too) is missing in 2.3.4-beta.  I just
copied the 2.3.3 version into my /usr/ode/server directory.

[damon 2/24/94 public]
This was missing in the Makefile. We moved it to a new location at the last
minute. Sigh.


CR Number                     : 1063
Short Description             : sup 2.3.4-beta breaks the -d switch
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : meissner (Michael Meissner)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 2/24/94
Found in Baseline             : 2.3.4
Found Date                    : 2/24/94
Severity                      : B
Priority                      : 2
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[meissner 2/24/94 public]
I loaded the 2.3.4-beta ODE on to my machine, and sup does not work with the -d
switch.  I get the error:

bash# sup -d -o -e supfile passwd root usr ccs share var local
>> FATAL ERROR in sup:
   argument: , not in -d's list of legal arguments.  List is:

No list is specified in the output (and -d has never taken a list).  I first
tried -doe and got the same error message.

[damon 2/24/94 public]
Doh! There seems to be a build dependency for sup. We will rebuild on a
different machine. In the meantime, I'll copy the old one into the beta area.
I'll also add a test case for sup to the test suite.

[damon 2/24/94 public]
Added 'sup no_supfile' test.

The test basically does a 'sup -d' with no supfile listed.

This test fails using a sup built on orion, but passes otherwise.

This will need to be tracked down on orion. Sounds like an uninitialized
variable. As an aside, this has been around for a few releases, but sup
hasn't been touched so we keep using the old one. Unfortunately, that fell
through the cracks this time. Better to have it tested anyway.

[damon 3/1/94 public]
Passed 'sup no_supfile' test after being built on orion. getopt() was setting
optarg to '\0' instead of NULL. Both cases are now tested for.


CR Number                     : 1062
Short Description             : bco does not check permissions
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : ohara (Abigail OHara)
Reported Date                 : 2/24/94
Found in Baseline             : 2.3.3
Found Date                    : 2/24/94
Severity                      : C
Priority                      : 2
Status                        : fix
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : sci.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 2/24/94 public]
If you have a file which is a link, for instance, and it is owned by
some one other than you, bco will appear to work but it won't update the file
and it doesn't complain.

[marty 2/24/94 public]
bco will now report any problems it has overwriting files in a sandbox
during a check-out.


CR Number                     : 1061
Short Description             : bco -undo error ?
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : robert (Rob Dicamillo)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 2/24/94
Found in Baseline             : 2.3.4
Found Date                    : 2/24/94
Severity                      : C
Priority                      : 0
Status                        : fix
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : bco.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[robert 2/24/94 public]

Did I not set something up correctly for 2.3.4 - I'm not sure
why it's looking for a redundant rat_test subdir,
or the stat error below for ./rat_test/rat_test/dummy ?

It appears that after having bco'd rev 1.1.5.2 on my branch, undo gets
rid of the copy in my sandbox, but does not update the RCS history?

Note below that bco is aliased to bco -verbose in my .sandboxrc.
 
blog -A after checking out 1.1.5.2:

- - - - - - - - - - - - - - - - - -

access list:
symbolic names:
        robert_dipc_sand: 1.1.5
        DIPC_SHARED: 1.1.4
        nmk16_1: 1.1.2.2
        OSC1_3_NORMA: 1.1.2
comment leader: "# "
keyword substitution: kv
total revisions: 6;     selected revisions: 6
description:
1.1.5.1>1.1.4.1;1.1.4.1>1.1.2.2;1.1.2.1>1.1;
----------------------------
revision 1.1
date: 1990/01/01 00:00:00;  author: bernadat;  state: Exp;
branches:  1.1.2;  1.1.4;  1.1.5;
*** Initial Trunk Revision ***
----------------------------
revision 1.1.5.2
date: 1994/02/24 17:31:42;  author: robert;  state: Exp;  lines: +4 -1
        test
----------------------------
revision 1.1.5.1
date: 1994/02/14 21:25:14;  author: robert;  state: Exp;  lines: +21 -0
*** Initial Branch Revision ***
----------------------------
revision 1.1.4.1
date: 1994/02/14 21:09:45;  author: robert;  state: Exp;  lines: +17 -0
        test
        [1994/02/14  21:08:20  robert]
----------------------------
revision 1.1.2.2
date: 1994/01/27 14:37:21;  author: bernadat;  state: Exp;  lines: +5 -0
        test
        [1994/01/27  14:37:02  bernadat]
----------------------------
revision 1.1.2.1
date: 1994/01/27 14:32:27;  author: bernadat;  state: Exp;  lines: +6 -0
        test
        [1994/01/27  14:31:56  bernadat]
=============================================================================
robert@highlander:/usr/sandbox/robert/dipc_sand/src/rat_test 122 % ls
dummy
robert@highlander:/usr/sandbox/robert/dipc_sand/src/rat_test 123 % ll *
-rw-r--r--   1 robert   system              446 Feb 24 12:31 dummy
robert@highlander:/usr/sandbox/robert/dipc_sand/src/rat_test 124 % bco -undo dummy
>  The revision corresponding to
>  rev: robert_dipc_sand
>  is revision: 1.1.5.2.
>  The revision corresponding to
>  rev: robert_dipc_sand;;DIPC_SHARED;nmk16_1;osc1_3b6;<1994/01/28,10:00
stat error: >  is revision: .
>> ERROR in bco:
>> File ./rat_test/rat_test/dummy is not under source control.
Could not open file './rat_test/rat_test/dummy'
./rat_test/rat_test/RCS/dummy,v: No such file or directory
File ./rat_test/dummy has been replaced by the latest revision on your private branch.
robert@highlander:/usr/sandbox/robert/dipc_sand/src/rat_test 125 % ls
robert@highlander:/usr/sandbox/robert/dipc_sand/src/rat_test 126 % !blog
blog -A dummy

RCS file: ./rat_test/dummy,v
Working file: dummy
head: 1.1
branch:
locks:
access list:
symbolic names:
        robert_dipc_sand: 1.1.5
        DIPC_SHARED: 1.1.4
        nmk16_1: 1.1.2.2
        OSC1_3_NORMA: 1.1.2
comment leader: "# "
keyword substitution: kv
total revisions: 6;     selected revisions: 6
description:
1.1.5.1>1.1.4.1;1.1.4.1>1.1.2.2;1.1.2.1>1.1;
----------------------------
revision 1.1
date: 1990/01/01 00:00:00;  author: bernadat;  state: Exp;
branches:  1.1.2;  1.1.4;  1.1.5;
*** Initial Trunk Revision ***
----------------------------
revision 1.1.5.2
date: 1994/02/24 17:31:42;  author: robert;  state: Exp;  lines: +4 -1
        test
----------------------------
revision 1.1.5.1
date: 1994/02/14 21:25:14;  author: robert;  state: Exp;  lines: +21 -0
*** Initial Branch Revision ***
----------------------------
revision 1.1.4.1
date: 1994/02/14 21:09:45;  author: robert;  state: Exp;  lines: +17 -0
        test
        [1994/02/14  21:08:20  robert]
----------------------------
revision 1.1.2.2
date: 1994/01/27 14:37:21;  author: bernadat;  state: Exp;  lines: +5 -0
        test
        [1994/01/27  14:37:02  bernadat]
----------------------------
revision 1.1.2.1
date: 1994/01/27 14:32:27;  author: bernadat;  state: Exp;  lines: +6 -0
        test
        [1994/01/27  14:31:56  bernadat]
=============================================================================
robert@highlander:/usr/sandbox/robert/dipc_sand/src/rat_test 127 % ll *
No match.

[damon 2/24/94 public]
bco -undo fails when you are not in the src directory. The work-around is
to move to the src directory and run bco -undo from there.

[damon 2/24/94 public]
Test 'bco undo' updated. Now fails. Operations are run from the 'subdir'
subdirectory. All files are explicitly listed. Test suites are cool. :-)

[marty 2/24/94 public]
bco not figures out the correct pathname to the file being undone.


CR Number                     : 1060
Short Description             : skipto() should handle negative chars
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 2/23/94
Found in Baseline             : 2.3.3
Found Date                    : 2/23/94
Severity                      : B
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 2/23/94 public]
In skipto(), there is an array called tab[] that can be accesed with an
index < 0. This causes datestrip to fail while running the test suite.

[damon 3/1/94 public]
All tests pass.


CR Number                     : 1056
Short Description             : separate sup programs
Defect or Enhancement?        : enh
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 2/17/94
Found in Baseline             : 2.3.4
Found Date                    : 2/17/94
Severity                      : C
Priority                      : 3
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 2/17/94 public]
While making sup pedantic, I realized that three programs were residing in the
sup dir: sup, supscan, and supfilesrv. I am moving supscan and supfilesrv
to their own dirs in ./ode/server/ . I am also creating a ./lib/libsup/ dir
for the common sup functions.


CR Number                     : 1054
Short Description             : mksb creating link and tools dir in non ode build env
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 2/11/94
Found in Baseline             : 2.3.3
Found Date                    : 2/11/94
Severity                      : C
Priority                      : 0
Status                        : cancel
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 2/11/94 public]
When the ODE build environment is not being used, mksb should not create
a link or a tools directory. Most of the non ODE build functionality of mksb
is working, it is just these two items that are not working.

[damon 2/11/94 public]
Lost my mind for a moment. People may want to have a tools dir even if
they are not using an ODE build environment, and will want to use links as
well.


CR Number                     : 1052
Short Description             : bco -p changes permissions on files
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 2/10/94
Found in Baseline             : 2.3.4
Found Date                    : 2/10/94
Severity                      : C
Priority                      : 0
Status                        : fix
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : lib/libode/sci.c
Responsible Engr.             : 
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : handson
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 2/10/94 public]
If a file is rw and a bco -p is done, the permissions on the file are changed
to read-only.

[marty 2/10/94 public]
Easy fix.  No problem.


CR Number                     : 1051
Short Description             : supscan coredump
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : supscan
Reported by                   : alan (Alan Hamilton)
Reported by Company           : osf
Interest List CC              : ratosc
Reported Date                 : 2/8/94
Found in Baseline             : 2.3.3
Found Date                    : 2/8/94
Severity                      : A
Priority                      : 0
Status                        : fix
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[alan 2/8/94 public]
To get the ode2.3.3 supscan to core dump, go to server2:/u0/release/at386/sup
and run ./scanit2.3.3 .

[damon 2/10/94 public]
This has been duplicated on presto.
Upgraded priority: stop-ship.

[damon 2/10/94 public]
Wow. You see the damnedest things on this project:

static makescanfile (scanfile)
{
        FILE *scanF;                    /* output file for scanned file list */

        (void) Tprocess (listT,recordone,scanF);
}

recordone (t,scanF)
TREE *t;
FILE **scanF;
{
        fprintf (*scanF,"%o %d %d %s\n",
                t->Tmode,t->Tctime,t->Tmtime,t->Tname);
}

I changed the **scanF to *scanF and removed the * from references to scanF.

This has been this way since at least ODE 2.1 and most likely forever. :-(

[damon 2/10/94 public]
Same was true for recordexec().

[alan 2/14/94 public]  HAPPY VALENTINE'S DAY
I started using the new supscan on Friday (or whenever Damon updated
supscan in the ode2.3.3tools area on server2).  Today I discovered
that (most of) the scan files it generated contained only the line "V2"!

To test it, go to server2:/u0/release/at386/sup and run ./scanit.2.3.3 .
Then run ./scanit to construct the correct scan files.

[damon 2/14/94 public]
Arg. The fix that I made stopped the core dumps but was not the right thing
to do. The real problem is that the pedantic checking has been over-ridden
in the sup dir be re-defining CFLAGS. This means that some problems have
been covered up. The worst offender, and the cause for the problem described
in this CR is a pointer being cast to an integer. On the alpha, that turns
a 64 bit pointer into a 32 bit integer. The integer is then re-cast into
a pointer. This removes 32 bits of information. I have fixed the immediate
problem and will turn pedantic checking on for sup.

I will put the new supscan in server2:/u0/ode2.3.3tools .


CR Number                     : 1049
Short Description             : remove build warnings and Errors
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 2/8/94
Found in Baseline             : 2.3.4
Found Date                    : 2/8/94
Severity                      : D
Priority                      : 0
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole), marty (Marty Lynch)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 2/8/94 public]

Only the following warnings are acceptable in building ODE:

*updtodate* because we don't care about this program,

"warning: `rcsid' defined but not used" because it is true and there isn't
much we can do about it.

[damon 2/22/94 public]

Revision of the statements from above:

Only the following warnings are acceptable in building ODE:

Anything in updtodate.c or mmindex.c because we don't care about these programs,

"warning: `rcsid' defined but not used" because it is true and there isn't
much we can do about it.

implicit declaration of select, flock, and gethostname because these are system
dependent.

[damon 2/22/94 public]
Also, ntohl is system dependent.

[damon 3/14/94 public]
ui_print_revision() is okay too. It will go away when the programs that
print a warning for it are updated to use the ODE parser.


CR Number                     : 1041
Short Description             : copyright and history documentation required
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : doc
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : bci (also bsubmit?)
Reported by                   : alan (Alan Hamilton)
Reported by Company           : osf
Interest List CC              : ratosc
Reported Date                 : 2/6/94
Found in Baseline             : 2.3.3
Found Date                    : 2/6/94
Severity                      : B
Priority                      : 0
Status                        : fix
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : ode/doc/sag/back.tree.mm
Responsible Engr.             : 
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[alan 2/6/94 public]
The copyright checking code in bci seems to expect every copyright from
  <comment leader>COPYRIGHT NOTICE
until the next line which has no <comment leader> to be either
  <comment leader><whitespace>
or a copyright listed in rc_files/<project>/copyrights .

Example:


pluto 167 % bco osf1_server/conf/files
./osf1_server/conf/files
pluto 168 % head osf1_server/conf/files
#
# COPYRIGHT NOTICE
# 
# Copyright (c) 1990, 1991, 1992, 1993 Open Software Foundation, Inc.
# ALL RIGHTS RESERVED (OSF/1).  See /usr/include/COPYRIGHT.OSF1 .
#
#
# Mach Operating System
# Copyright (c) 1989 Carnegie-Mellon University
# All rights reserved.  The CMU software License Agreement specifies
pluto 169 % bci -auto -m "test" osf1_server/conf/files
>> WARNING in bci:
>> The copyright section contains an invalid copyright.
>> The invalid copyright starts with:
>> 'Mach Operating System Copyright (c) 198'
>> WARNING in bci:
>> Improper markers or history section in file ./osf1_server/conf/files
pluto 170 % 


This feature is not documented in either the DUG or SAG, and is
causing us significant problems.

I have set "Severity=A" because bci's current copyright checking makes
the copyright checking feature unusable for the OSC.  I have set
"Priority=1" because I believe this has to be addressed in ode2.3.4.

[damon 2/7/94 public]
Stop ship: P0. No workaround, but not catastrophic: severity B.
However, from looking at the two copyright files, I cannot find the Mach
copyright. If it is not desired to have this copyright checked for, then
we will need to have some discussion.

[alan 2/7/94 public]
As the documentation did not specify that the COPYRIGHT NOTICE had to
be terminated by an unambiguous end-of-comment (which for "# "
comments means a non-comment line), the OSC Rats did not provide one.
However, ode2.3.3 apparently deimplements the feature of ode2.1 that
assumes that a history or copyright comment ends with a line it does
not recognize (see also ode CR# 865, now closed).

[damon 2/8/94 public]
I don't follow that last sentence about history and copyright comments ending
with a line it does not recognize. Reading CR 865 doesn't help me either.
Also, since ode2.1 did not do anything with COPYRIGHT NOTICE, how could we
have de-implemented anything regarding it? Please elaborate. Also, my
question in my note of 2/7/94 has not been answered. A yes or no may clear
this whole thing up.

[damon 2/8/94 public]
The code doesn't seem to like a blank line between copyrights. This is
wrong.

[damon 2/8/94 public]
Oops. Sorry. I was wrong. It doesn't mind the blank line.

[alan 2/8/94 public]
If your question of 2/7/94 was:

  Do you want this copyright not checked?

the answer is:

  Yes.  This file with the copyright marker was valid for ode2.1 .
  When we expanded the copyright notice and had ode2.3.3 check
  copyrights, it refused to check in the file.  That's what I meant by
  "deimplements the feature of ode2.1": that it treats the copyrights
  differently, and the documentation does not tell what you have to have
  to terminate a copyright notice.

In tests in your office, we determined that a COPYRIGHT NOTICE section
is terminated by a non-comment line or a HISTORY line.  The OSC Rats
can determine exactly which files have <something other than an OSF
copyright> between the COPYRIGHT NOTICE line and the end of that
section.  Then we can either place <something other than an OSF
copyright> in the copyrights file or remove it from the COPYRIGHT
NOTICE section.

As I don't necessarily disagree with the design of the COPYRIGHT
NOTICE section, I am changing this to a doc CR.  The new request is
for clear documentation of how ode determines the start and end of
copyright and history sections, and what it requires and forbids in
them.

[marty 2/15/94 public]
The "System Administrators Guide" and the ode2.3.4 release notes have been
changed to document the new COPYRIGHT NOTICE handling  described above.


CR Number                     : 1040
Short Description             : ode not using subproject copyrights file
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : alan (Alan Hamilton)
Reported by Company           : osf
Interest List CC              : ratosc, meissner (Michael Meissner)
Reported Date                 : 2/4/94
Found in Baseline             : 2.3.3
Found Date                    : 2/4/94
Severity                      : B
Priority                      : 0
Status                        : cancel
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 
Affected File(s)              : 
Responsible Engr.             : 
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[alan 2/4/94 public]
bcreate (and presumably bci and bsubmit) don't use the subproject
copyrights file.

On the osc, the default copyright for the main project is the
OSF_COPYRIGHT, but on the mach3 subproject it is OSF_FREE_COPYRIGHT.

However, when I create a file in one of the mach3 subproject
directories, it is created with the COPYRIGHT NOTICE DEFAULT from the
project copyrights file.

[damon 2/7/94 public]
This is a stop-ship, thus priority 0. No workaround, so severity B.

[damon 2/7/94 public]
I have been unable to duplicate this problem. If I bcreate files from
subdirectories I get different copyrights. I tried this backed by osc1.3.

[alan 2/7/94 public]
I can't check it now, because I had to turn off check_copyrights (see
ode CR# 1042).  It will have to wait until that is fixed, or be tested
in another environment.

[marty 2/10/94 public]
Alan, 
   I have set up the ode2.3.4 backing tree to have subprojects (with different
copyrights) and I am unable to reproduce this problem.  Feel free to 
set up a sandbox backed by ode2.3.4 and test 'bcreate'.  Creating files
in the  subdirectory "rat_test" and the subdirectory "ode" will give 
you different copyrights.  
   If you can reproduce this problem, please contact one of us.  If not,
please cancel this CR.

[alan 2/14/94 public]
  I don't have time to try to reproduce this, so I am closing it.
If it shows up again, we'll open another, but unless that happens,
we're golden.


CR Number                     : 1034
Short Description             : regression: bsubmit -resub broken
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : yak (Yakov Burtov)
Reported Date                 : 2/3/94
Found in Baseline             : 2.3.4
Found Date                    : 2/3/94
Severity                      : A
Priority                      : 0
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 2/3/94 public]
bsubmit -resub produces:

Entering bsubmit
----------------

Checking environment
--------------------
2/03/94
%

And just returns to the prompt. The date that comes up is part of what bsubmit_s
is passing back to the client in case the submission gets interrupted. So,
something more than what is supposed to get passed back is being passed
back.

[damon 2/3/94 public]
This was a result of 2 changes: CR 895 and CR 890.

CR 895 addressed a canonicalization problem which make_resub_list() in
bsubmit_m.c was incorrectly depending on. make_resub_list() now correctly
calls sci_add_to_list_as_is().

CR 890 checked for consistency with branches, but did not take into account
that this might be a resubmission. This change has been temporarily rolled
back.

Passed 'bsubmit resub' test.


CR Number                     : 1030
Short Description             : ci called by bsubmit complains about improper revision
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : alpha
S/W Ref Platform              : osf1
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : yak (Yakov Burtov)
Reported Date                 : 2/1/94
Found in Baseline             : 2.3.3
Found Date                    : 2/1/94
Severity                      : A
Priority                      : 0
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 2/1/94 public]

On an alpha_osf1 machine, the test 'bsubmit simple' produces:

... ...

./subdir/1.sh
ci error: improper revision number: 1.1.(
rcs error: improper revision number: 1.1.(
>> FATAL ERROR in bsubmit:
>> Could not find newly created branch
>> for set: 'TEST'.
./subdir/deep/deep/deep/deep/file.c

... ...

This looks like an uninitialized variable or 64 bit problem.

[damon 2/2/94 public]
This went away in 2.3.4. Probably the result of a CR with wider scope.
Passed 'bsubmit simple' test.


CR Number                     : 1029
Short Description             : update release notes for 2.3.4
Defect or Enhancement?        : enh
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 2/1/94
Found in Baseline             : 2.3.3
Found Date                    : 2/1/94
Severity                      : A
Priority                      : 0
Status                        : open
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole), marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 2/1/94 public]

[damon 2/8/94 public]

I have updated the following files:

change_requests
changelog
release_notes.users

I have changed the make files so that the release_notes.* files get installed
into $TOSTAGE/doc  .

[damon 2/8/94 public]
I added the following install targets:
changelog
change_requests

This way, users can easily find out what is in a release.

This just needs to be updated as 2.3.4 is changed as a result of alpha and
beta testing.


CR Number                     : 1027
Short Description             : convert 2.3.4 build into full build
Defect or Enhancement?        : enh
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 1/31/94
Found in Baseline             : 2.3.3
Found Date                    : 1/31/94
Severity                      : C
Priority                      : 0
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 1/31/94 public]
This will make our builds cleaner and also mean that people looking for
something in ODE don't have to look in more than one place.


CR Number                     : 1025
Short Description             : sadmin -edit log scrambles permissions
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : jeffc (Jeff Carter)
Reported by Company           : osf
Interest List CC              : ratosc
Reported Date                 : 1/31/94
Found in Baseline             : 2.3.3
Found Date                    : 1/31/94
Severity                      : B
Priority                      : 1
Status                        : fix
Duplicate Of                  : 
Fix By Baseline               : 2.3.4,2.3.5
Fixed In Baseline             : 2.3.4,2.3.5
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[jeffc 1/31/94 public]
In cleaning up behind the blown submit that was the subject of CR1024,
I used "sadmin -edit log" to patch the part of the bsubmit log that was
incorrect.

At the conclusion of the operation, the bsubmit.log file was left mode 600
(not readable by anyone but devsrc)

[damon 3/3/94 public]
Due to some unix weirdness, opening a file for writing and then locking the
file depends on running a chmod to guarantee write permission prior to
the open. The chmod just set the user permissions.


CR Number                     : 1023
Short Description             : bsubmit does not allow user to abort if merge required.
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : jeffc (Jeff Carter)
Reported by Company           : osf
Interest List CC              : osf1-team
Reported Date                 : 1/28/94
Found in Baseline             : 2.3.3
Found Date                    : 1/28/94
Severity                      : B
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[jeffc 1/28/94 public]
The new improved bsubmit command no longer gives the developer the 
opportunity to abort the submission if a merge is required. Since it
is VERBOTEN to submit files that are untested (and a file that gets 
merged after final review & test is untested) this is very bad behavior.

Log of the incorrect busbmit seession:

jeffc@soba 619 > bsubmit -defect 10507 mach/mach.defs vm/vm_user.c

Entering bsubmit
----------------

Enter your full name for the log: [Jeff Carter] 
Outdate the submitted files from set: jeffc_old?
Answer: [<y>|n] 

Checking environment
--------------------

Validating submission
---------------------
The following file(s) will require user
interaction during the merge step:
  ./mach_kernel/mach/mach.defs
  ./mach_kernel/vm/vm_user.c
Merges required
./mach_kernel/mach/mach.defs

*** WARNING -- calculated common ancestor ***
*** Check the merge differences carefully ***

Merge successful.
Abort, ok, edit, merge, rco, co,
rdiff, diff, leader  [rdiff]  

(diffs omitted for brevity)
Abort, ok, edit, merge, rco, co,
rdiff, diff, leader  [ok]  
./mach_kernel/vm/vm_user.c

*** WARNING -- calculated common ancestor ***
*** Check the merge differences carefully ***

Merge successful.
Abort, ok, edit, merge, rco, co,
rdiff, diff, leader  [rdiff]  

Abort, ok, edit, merge, rco, co,
rdiff, diff, leader  [ok]  
Command? (type "help" for a list)  [check-in]  
./mach_kernel/mach/mach.defs
Command? (type "help" for a list)  [check-in]  
./mach_kernel/vm/vm_user.c
RCS file: ./mach_kernel/mach/mach.defs,v
done
RCS file: ./mach_kernel/vm/vm_user.c,v
done

Checking environment
--------------------

Validating submission
---------------------
No user interaction will be required.

Submitting files
----------------
./mach_kernel/mach/mach.defs
./mach_kernel/vm/vm_user.c

[damon 1/28/94 public]
I'm not sure I understand this. Aren't those prompts listed above? You can
abort from those prompts without doing the merge. If you mean abort AFTER
the merges are done, there never was such an option.

There is a CR for dissallowing merges in bsubmit: CR 427. If this is what
is really desired, I'd like to dup this CR.

[jeffc 1/30/94 public]
No, I'm not talking about aborting (or avoiding) the merges. Either of these
would be bad, as it implies you are overwriting data in the backing tree.

There used to be a prompt following the "merges required" message that
requested the user to confirm whether to continue with the submit process.

Since aborting a submit manually (^C) usually leaves the hold file or RCS
files in an inconsistent state (regardless of the copious messages assuring
you to the contrary) this is usually ill-advised. Also, given that bstat -a
is broken, there is no way for a developer to check in advance that a merge
is required. Attempting the submit is the only real way of determining that
a merge is/is not required.

[damon 1/31/94 public]
I don't remember such a prompt, but that isn't important.

By aborting at the merge prompt, you will leave bsubmit as you have requested.
Aborting the merge does not skip merging, it aborts the whole bsubmit.
I should have been more precise.

In CR 427 we describe setting a project variable that would not let you proceed
if merges were required and you would have to run bmerge before running bsubmit
again. This process would hopefully encourage users to test the results of
their merges. I'd still like to dup this to 427.

[damon 2/1/94 public]
Eek! I looked through some old code and there was indeed such a prompt prior
to the actual merge prompts. My apologies. Since there is a workaround I have
lowered the severity and priority. Not sure if we can include this in 2.3.4
at this point.

[damon 2/2/94 public]
Sometimes I can be pretty thick-headed.

Let's say you want to submit 10 files as a unit, but if there is a merge
required, you want to run bmerge and do testing before submitting. So you
go to submit the files and it turns out that file 5 needs to be merged.
bsubmit won't give you a merge prompt until _after_ it has submitted the first
4 files. At that point the prompt is too late.

The original merge prompt needs to be restored.

[damon 2/4/94 public]
The original merge prompt has been restored.
The test 'bsubmit merge' has been updated.
Test 'bsubmit merge' passed.


CR Number                     : 1020
Short Description             : can not find ancestry when both
branches have trunk rev as ancestor
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : jeffc (Jeff Carter)
Reported Date                 : 1/28/94
Found in Baseline             : 2.3.3
Found Date                    : 1/28/94
Severity                      : B
Priority                      : 0
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 1/28/94 public]
Have to go to a meeting will fill in details after.

[damon 1/28/94 public]
Let's say you have ancestry like:

3.0.8.1>3.0;3.0.6.1>3.0;

And you want the common ancestor of 3.0.8.2 and 3.0.6.4.
The ancestry searching code will stop at 3.0 and not look for successors of
3.0 to match against.

Correct behaviour would be:

3.0.8.2 3.0.6.4
3.0     3.0.6.4 [3.0.8.1 > 3.0 ]
3.0     3.0     [3.0.6.1 > 3.0 ] (MATCH)

[damon 1/28/94 public]
Removed code which stopped ancestry determination at trunk revs. Removed
getancestor2() procedure which should have been a pass-through and thus
uneccessary.

[damon 1/30/94 public]
Passed 'bstat ancestor_is_trunk' test.


CR Number                     : 1014
Short Description             : Years characters should include "-"
Defect or Enhancement?        : enh
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : alan (Alan Hamilton)
Reported by Company           : osf
Interest List CC              : rat, rice (Renee Rice)
Reported Date                 : 1/26/94
Found in Baseline             : 2.3
Found Date                    : 1/26/94
Severity                      : C
Priority                      : 2
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[alan 1/26/94 public]
Renee Rice of Legal suggests that we use "1990-1994" instead of "1990,
1991, 1992, 1993, 1994" in our copyrights.  We will need ode to
recognize "-" as a valid character in @YEARS@ to do so.

[yakov 1/27/94 public]
I would like this CR to be fixed in 2.3.4.
I am going to update the copyright notices in VTS 2.0 files (around 1500
files). If this CR is fixed in 2.3.4, I'll be able to put the 'better'
copyrights in.

[damon 1/28/94 public]
Modified test 'bci history_separated' to have files with:

# Copyright (c) 1993, 1992, 1991-90 Open Software Foundation, Inc.

and 

 * Copyright (c) 1993-92, 1991, 1990 Open Software Foundation, Inc.

Passed 'bci history_separated' test.


CR Number                     : 1013
Short Description             : merging with bsubmit deosn't work on at386_sinix
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : marty (Marty Lynch)
Reported by Company           : osf
Interest List CC              : Norbert.Marrek@mch.sni.de
Reported Date                 : 1/25/94
Found in Baseline             : 2.3
Found Date                    : 1/25/94
Severity                      : B
Priority                      : 0
Status                        : fix
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : libode/error.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[marty 1/25/94 public]
Abby Ohara has found that when she is using bsubmit and a merge is
required, bsubmit stops with the message:

"An invalid error has occurred".

and then stops.

[marty 1/25/94 public]
It turns out that the routine err_log() had a slight 
problem with va_args processing.  It was trying 
to muck around with argument variables  before calling
va_arg() to process the variables.  This processing is different
from sinix and all other platforms (that why we havn't seen the
problem anywhere else).

[damon 1/28/94 public]
Does Norbert have this?


CR Number                     : 1005
Short Description             : bmerge core dumps after a complete bsubmit!
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : robert (Rob Dicamillo)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 1/21/94
Found in Baseline             : 2.3
Found Date                    : 1/21/94
Severity                      : C
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[robert 1/21/94 public]

Far be it from me to understand why a developers would try and do
a bmerge in their sandbox after they've already bsubmitted, but with
the 2.3.3 version of bmere, this core dumps.

- rob

[damon 1/21/94 public]
This was fixed as a result of other work.
Passed 'bmerge after_submit' test.


CR Number                     : 1004
Short Description             : mklinks ignores -sb switch
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 1/21/94
Found in Baseline             : 2.3
Found Date                    : 1/21/94
Severity                      : C
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : mklinks.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 1/21/94 public]
If you are in a sandbox other than the default and specify -sb, mklinks
still assumes you want the default sandbox:

>> FATAL ERROR in mklinks:
   current directory /project/test/users/sandboxes/test2/src not in sandbox.
USAGE:

< usage message left out >

[marty 1/25/94 public]
Fixed.  You may now use the "-sb" option.

[damon 1/27/94 public]
Passed 'mklinks link_in_sb_path' test which uses the -sb switch of mklinks.


CR Number                     : 1003
Short Description             : bcreate -undo should not remove files
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 1/21/94
Found in Baseline             : 2.3.4
Found Date                    : 1/21/94
Severity                      : A
Priority                      : 0
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : sci.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 1/21/94 public]
This is probably a regression, but I'm not sure. This was originally placed in
the test suite as correct behaviour.

Apparently, this has been expected behaviour for a while. However, I think
this should be changed because you may be bcreate -undoing a file that
bcreate did not create. I.e., you have a file, you bcreate it, you decide
you wanted it to be a different name, you bcreate -undo it... now it is
gone.

[marty 1/24/94 public]
Now, bcreate -undo will remove the file from source control
(as it always did) and leave the file intact in the users sandbox.

[damon 1/27/94 public]
Modified 'bcreate undo' test to check for existance of files after
bcreate -undo.
Passes 'bcreate undo' test.


CR Number                     : 1002
Short Description             : Regression: bcreate -undo overzealous
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 996
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : meissner (Michael Meissner), damon (Damon Poole)
Reported Date                 : 1/20/94
Found in Baseline             : 2.3
Found Date                    : 1/20/94
Severity                      : C
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : error.c,sci.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 1/20/94 public]
When a file has just been bcreated and then bci'd, a bcreate -undo should
complain and do nothing. It still complains, but it now removes the user's
branch label.

[marty 1/24/94 public]
You're right.  I have changed bcreate so that if there is  users private
branch (1.1.1.2) then it will complain and tell the user to use 'bcs -o'
first.

[damon 1/24/94 public]
The message the bcreate -undo gives in this case is:

Cannot remove file while it still has revision 1.1.1.2 -- try bcs -o first
[ deleting branch name 'ode_user_test' ]
>> ERROR in bcreate:
>> The file ./1.sh could not be removed from source control.

The '[ deleting...]' part should not appear.

Still fails 'bcreate undo_checked_in' test. The symbolic name doesn't get
removed anymore though.

[marty 1/24/94 public]
The delet message has been removed.

[damon 1/31/94 public]
Too much got removed. Now it just says:

Cannot remove file while it still has revision 1.1.1.2 -- try bcs -o first

It should say:

Cannot remove file while it still has revision 1.1.1.2 -- try bcs -o first
>> ERROR in bcreate:
>> The file ./1.sh could not be removed from source control.

[marty 1/31/94 public]
If a file cannot be uncreated because a user has many
revisions checked in on the branch, he will get the message


Cannot remove file while it still has revision 1.1.1.2 -- try bcs -o first
>> ERROR in bcreate:
>> The file ./1.sh could not be removed from source control.

[damon 1/31/94 public]
Passed 'bcreate undo_checked_in' test!


CR Number                     : 1000
Short Description             : ODE segvs if ancestor cannot be found
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : masek, alan (Alan Hamilton)
Reported Date                 : 1/20/94
Found in Baseline             : 2.3
Found Date                    : 1/20/94
Severity                      : A
Priority                      : 2
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 1/20/94 public]
In some cases, if there is no ancestor for a pair of revisions, ODE generally
segvs. Instead, it should complain that there is no common ancestor.

[scholz 01/20/94 public]
Seems to me that if the thing segvs, it's a little more sever than C.

[damon 1/20/94 public]
In fixing another CR, an implied check was left out. I have put the check
back in. Basically, you need to check all revs in ancestry comparisons to
see if they are just two fields. If they are, then treat them accordingly
instead of trying to get three field branches out of them.

[damon 1/20/94 public]
The workaround for the sys-eng group is to take out the ancestry that indicates
that a merge has been done against 1.3. This is ok because they are submitting
to osc1.3.maint_sbox and not 1.3 .

[damon 1/30/94 public]
Passed 'special no_ancestor' test.


CR Number                     : 990
Short Description             : bco -read gives weird error
message if file doesn't exist
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : zeliff (Rich Zeliff)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 1/14/94
Found in Baseline             : 2.3
Found Date                    : 1/14/94
Severity                      : C
Priority                      : 3
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : sci.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[zeliff 1/14/94 public]
If I do a 'bco -read' on a file that doesn't exist, I get the following
error message:

gemini gds/src$ bco -read Buildconf.exp
stat err>> WARNING in bco:
>> File does not contain the revision specified. 
>> File: ./Buildconf.exp
>> Revision: zeliff_gds;;DCE1_1;DCE1_1I;DCE1_0_3;DCE1_0_3I;DCE1_0_2A;DCE1_0_2;<1992/01/19,18:00
Revision E of file 'zeliff_gds;;DCE1_1;DCE1_1I;DCE1_0_3;DCE1_0_3I;DCE1_0_2A;DCE1_0_2;<1992/01/19,18:00' does not exist
or: ./RCS/Buildconf.exp,v: No such file or directory


gemini gds/src$ bco -version               
program :  bco
release :  ODE 2.3.3
libode  :  Thu Nov 11 14:00:27 EST 1993

[marty 1/14/94 public]
No problem.  When doing a check out "read-only" and the file does not
exist.  The error message will be

>> ERROR in bco:
>> File ./ode/bin/bco/xxx.c is not under source control.
Could not open file './ode/bin/bco/xxx.c'

[damon 1/18/94 public]
This is covered by two tests: 'bco not_exists_read' and
'bco not_exists'. These tests test bco on files that don't exist and
bco -read of files that don't exist. Both tests pass.


CR Number                     : 988
Short Description             : resb complains about backing project line with no reason
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : rec (Ronald Czik)
Reported by Company           : osf
Interest List CC              : yak (Yakov Burtov)
Reported Date                 : 1/13/94
Found in Baseline             : 2.3.3
Found Date                    : 1/13/94
Severity                      : C
Priority                      : 1
Status                        : fix
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : 
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[rec 1/13/94 public]
Did the following in a using 2.3.3 tools:

resb /project/motif/build/motif1.2.4-h.s
...
resb /project/motif/build/motif1.2.4-h.s

and got the following error:

rec@europa {433} resb /project/motif/build/motif1.2.4-h.s
>> WARNING in resb:
>> backing_project line missing in sandbox rc file.
Internal error


Also, last time when I specified a non existant build, I could not
recover and had to remove the sandbox and start again.

[damon 2/1/94 public]
I think this was fixed, but we need to add a specific test case. I have
lowered the severity because the workaround is to do the resb manually.

[damon 2/3/94 public]
We have been unable to reproduce this problem, but I don't think it will
pop up again. Since we have no test case which will show that this problem
no longer exists, I don't think we can close this. However, I will mark it
as fixed and see if it crops up again.


CR Number                     : 983
Short Description             : BCSSET no longer set in env
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : yak (Yakov Burtov)
Reported Date                 : 1/10/94
Found in Baseline             : 2.3
Found Date                    : 1/10/94
Severity                      : B
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : workon.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 1/10/94 public]

BCSSET is no longer being set by workon. Yakov needs this for some motif stuff.

[marty 1/19/94 public]
Yakov,

  I am assuming that you need this for some scripts.  Is is possible to 
get this information from `currentsb -set`?

Just curious,

Marty

[yakov 1/19/94 public]

Marty,

	I amn't using any BCS environment variables any more. I have replaced
them with the calls to 'bstat'. But maybe somebody else is using them?

[marty 1/19/94 public]
Well, I found that the documentation specifies that the BCSSET variable will
be set to the setname and can be used by anyone.  So, I changed 'workon'
to set it in the environment.
Fixed.

[damon 1/21/94 public]
Passed modified 'workon simple' test.


CR Number                     : 979
Short Description             : mksb complains that build is not upgraded if it does not exist
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : mksb
Reported by                   : alan (Alan Hamilton)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 1/7/94
Found in Baseline             : 2.3
Found Date                    : 1/7/94
Severity                      : D
Priority                      : 4
Status                        : dup
Duplicate Of                  : 749
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[alan 1/7/94 public]

pluto 87 % mksb oscmaint
No known current builds to pick from.
Enter absolute path to backing tree or name from build list: /project/osc/buld/osc1.2.maint_sbox
>> WARNING in mksb:
>> The build /project/osc/buld/osc1.2.maint_sbox apparently needs to be upgraded.

The actual errors is that "buld" should be "build", but the error
printed suggests that there is something wrong with the build that
exists.

[marty 1/10/94 public]
Alan,

I agree that the message you got from 'mksb' is misleading.
Unfortunately, we can't put code in 'mksb' that checks for possible
spelling errors.  It turns out that there are two ways in which 'mksb'
complains about backing chains:

   1) When the backing chain is not where you say it is (misspelled
pathname)

   2) The backing tree was incorrectly set up.  (Some necessary files
are missing).

   For CR # 749 (which is pretty close to this CR) we changed 'mksb'
so that it would specifically print out the files it was expecting to
find.  For instance: in the example above the output would be:

mksb -back /project/osc/buld/osc1.2.maint_sbox -m at386_osf1 -dir `pwd` xyxxz
>> WARNING in mksb:
>> could not get project directory or default build.
>> FATAL ERROR in mksb:
>> The backing tree /project/osc/buld/osc1.2.maint_sbox is incorrectly set up.
>> Could not read the file /project/osc/buld/osc1.2.maint_sbox/rc_files/projects

[alan 1/28/94 public]

I think the following:

>> The backing tree /project/osc/buld/osc1.2.maint_sbox is incorrectly set up.

should change to:

>> Problem accessing backing tree /project/osc/buld/osc1.2.maint_sbox.


CR Number                     : 977
Short Description             : bci core dumps on 0-length files
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : bci
Reported by                   : alan (Alan Hamilton)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 1/6/94
Found in Baseline             : 2.3
Found Date                    : 1/6/94
Severity                      : C
Priority                      : 2
Status                        : cancel
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 
Affected File(s)              : 
Responsible Engr.             : 
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[alan 1/6/94 public]
After a messy system failure, I had a 0-length file in my sandbox.
When I tried to check it in:

Missing HISTORY marker
Unexpected end of file
>> WARNING in bci:
>> Improper markers or history section in file ./seccmd/xif/isso/accounts/XMakeGroup.c
Segmentation fault (core dumped)

[damon 1/7/94 public]
The warning ( which should be an error ) is expected behaviour, but it
definately should not core dump.

[alan 1/14/94 public]
I can't reproduce this and neither can Marty, so I am cancelling it.


CR Number                     : 976
Short Description             : bmerge core dumps
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : bmerge
Reported by                   : alan (Alan Hamilton)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 1/6/94
Found in Baseline             : 2.3
Found Date                    : 1/6/94
Severity                      : A
Priority                      : 2
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : 
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[alan 1/6/94 public]

When logged in as gupta on kadabra using ode2.3.3 in
/u0/SandBox/osc_work/src, I got the following:

>bmerge -r OSF1_3 -all
Segmentation fault (core dumped)
>mount | grep usr/ode
server5:/u5/release/ode2.3.3/at386_osf1 on /usr/ode:  (read-only)
server5:/u6/release/ode2.2/at386_osf1 on /usr/ode2.2:

[damon 2/1/94 public]
'OSF1_3' is not a valid revision...
Passes test 'bmerge no_rev' test.


CR Number                     : 975
Short Description             : bmerge -common acts differently than bmerge
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 1/6/94
Found in Baseline             : 2.3
Found Date                    : 1/6/94
Severity                      : C
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 1/6/94 public]
bmerge -common treats BIN files differently than plain bmerge.
Plain bmerge doesn't deal with BIN files, while bmerge -common does. It should
act the same as plain bmerge.
Failed 'bmerge common' test.

[damon 1/6/94 public]
Passed 'bmerge common' test.


CR Number                     : 972
Short Description             : bco -p should ignore rw perm of file
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 1/5/94
Found in Baseline             : 2.3
Found Date                    : 1/5/94
Severity                      : B
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 1/5/94 public]
The following should not occur:

%bco -p -read -r 1.5.9.28 sci.c > out 
>> FATAL ERROR in bco:
>> File ./ode/lib/libode/sci.c is writeable.
>> This file may already be checked out for editing.
>> Check out read-only will not be performed for this file.

bco should not examine the file in the sandbox.

[marty 1/6/94 public]
Fixed.  You can "bco -p" any ol' time.

[damon 1/6/93 public]
Adjusted test 'bco stdout' to run on writeable files.
Passed revised 'bco stdout' test.


CR Number                     : 971
Short Description             : resb should complain about invalid backing build
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 1/4/94
Found in Baseline             : 2.3
Found Date                    : 1/4/94
Severity                      : C
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : resb.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 1/4/94 public]
resb should not resb to an invalid build!

Created new test: 'resb bad_build'. Fails.

[marty 1/12/94 public]
Put in more checks to make sure that the target backing tree is valid.

[damon 1/18/94 public]
The test 'resb bad_build' now passes.


CR Number                     : 968
Short Description             : bsubmit of defunct files leaves 2 #srvtmp* files behind
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/31/93
Found in Baseline             : 2.3
Found Date                    : 12/31/93
Severity                      : E
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : test
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 12/31/93 public]
Short description says it all. They are left in the rcs tree. This is minor
but the files will accumulate and clutter up directory listings.

[damon 1/19/94 public]
Temporary files were not being removed if files were defuncted. Routines:
sci_submit() and sci_real_fast_lookup_latest_rev_list().

Passed 'bsubmit defunct' test.


CR Number                     : 967
Short Description             : bcreate -undo does nothing with BIN and NONE files
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/31/93
Found in Baseline             : 2.3
Found Date                    : 12/31/93
Severity                      : B
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : ode/server/rcsacl/rcsacl.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : test
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 12/31/93 public]
The short description says it all. This was found by the
test 'bcreate undo' .

[damon 12/31/93 public]
The BIN and NONE files have an expansion mode of 'o' which is different
from other files and thus rm_rcs in rcsacl.c does not recognize the contents
of the rcs file. Therefore, the rcs file does not get removed. 
remove_empty_file() needs to be adjusted to recognize both possibilities.

[marty 12/31/93 public]
Fixed.  Comment leaders NONE and BIN add the line "expand *" to the rcs file.
This line was confusing "rcsacl" on the server side.

[damon 12/31/93 public]
Oh, how 'suite' it is! Now passes 'bcreate undo' test.


CR Number                     : 966
Short Description             : bstat dumps core.
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : yak (Yakov Burtov)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/30/93
Found in Baseline             : 2.3.3
Found Date                    : 12/30/93
Severity                      : A
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : bin/bstat/bstat.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[yak 12/30/93 public]

bstat  dumps core. 
Here is the log:
pmin4 /net/moonbeam/u1/sand/vts20/src 148 > resb -sb vts20 $MB/vts20-o
pmin4 /net/moonbeam/u1/sand/vts20/src 149 > bstat -all
fopen /project/motif/build/vts20-o/rc_files/vts/sc.conf: No such file or directory
>> WARNING in bstat:
>> rcs_host line missing in sandbox rc file.
>> WARNING in bstat:
>> source_host line missing in sandbox rc file.
>> WARNING in bstat:
>> rcs_relay line missing in sandbox rc file.
Segmentation fault (core dumped)
pmin4 /net/moonbeam/u1/sand/vts20/src 150 > 

I was in the sandbox made against /project/motif/build/vts2.0 build, and I 
re-targeted it against /project/motif/build/vts2.0-o.

[marty 1/4/93 public]
Fixed, you still get the warnings listed above, but, you don;t
get the segmentation fault.

[damon 1/18/94 public]
Passed 'bstat bad_backing' test.


CR Number                     : 964
Short Description             : bco -p should not print file name
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/30/93
Found in Baseline             : 2.3
Found Date                    : 12/30/93
Severity                      : D
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : test
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 12/30/93 public]
Test 'bco stdout' fails. File names are printing out when they should not.

[damon 12/30/93 public]
Now passes 'bco stdout'.


CR Number                     : 963
Short Description             : bsubmit accepts -changed switch
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/30/93
Found in Baseline             : 2.3
Found Date                    : 12/30/93
Severity                      : D
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : handson
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 12/30/93 public]
bsubmit should not accept the -changed switch, only the -saved switch.

[damon 1/6/94 public]
Removed -changed from bsubmit, added 'bsubmit -changed' to
'special no_such_option' test.
Passed 'special no_such_option' test.


CR Number                     : 962
Short Description             : mklinks is broken in ODE 2.3.3
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : yak (Yakov Burtov)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/29/93
Found in Baseline             : 2.3
Found Date                    : 12/29/93
Severity                      : A
Priority                      : 1
Status                        : fix
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : ode/bin/mklinks/mklinks.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[yak 12/29/93 public]

The latest mklinks in ODE 2.3.3 fails to make the right links if
-link_from argument is relative path.
Here is the test case:
pmin4 /tmp 114 > mkdir a1 a1/b1 a2
pmin4 /tmp 115 > touch a1/b1/f1
pmin4 /tmp 116 > mklinks -link_from a1 -link_to a2

Linking:
  From: a1
  To:   a2

Is this correct?  [yes]  
pmin4 /tmp 117 > ls -lL a2/b1
total 0
lrwxr-xr-x   1 yak      system               13 Dec 29 16:38 f1 -> a1//././b1/f1

ls -lL shows f1 file as a link, because this link can not be resolved.

The right solution for the mklinks (as it was before, for example in ODE 2.1)
is to use the whole path, and to link f1 in a2/b1 as /tmp/a1/b1/f1. Even 
better solution for mklinks is to use '../' to create the relative path: 
../../a1/b1/f1.  Sure '../' should be used only if both '-link_from' and 
'-link_to' are relative paths.

If mklinks creates '../' paths it will be greate, but at least the old
behaivior should be restored.

[marty 12/31/93 public]
Yakov,

  You have described two problems. 

  The problem with ".//././." in the pathname
has been fixed in a previous CR.  

  I just submitted a fix for the problem 
with "-link_from" generating incorrect links.  In you example above,
mklinks will now create
f1 -> /tmp/a1/b1/f1.
This behavior is the same as the ode2.1 "mklinks".


CR Number                     : 961
Short Description             : Very scary bsubmit message
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : bsubmit
Reported by                   : rsalz (Richard Salz)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/29/93
Found in Baseline             : 2.3
Found Date                    : 12/29/93
Severity                      : A
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[rsalz 12/29/93 public]
I did something like the following:
	bco foo
	vi foo
	bci foo
	bco bar
	bci -defunct bar
	bsubmit foo bar
And bsubmit said
	Outdating files
	---------------
	foo
	bar

Scared the hell out of me.  It did do the right thing, outdating only
bar while updating foo.

[damon 12/29/93 public]
'Outdating files' really means 'Outdating User Branches'. We'll change the
message so you can sleep at night. :-)

[zeliff 12/29/93 public]
Perhaps add a seperate message segment which reports defuncts (defunctions?
defuncations?) seperately from submissions...?

[damon 1/19/94 public]
Changed message as noted in my message above. Passed 'bsubmit simple' test
which was changed to reflect new message.


CR Number                     : 957
Short Description             : bdiff output contains kruft
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : zeliff (Rich Zeliff)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/29/93
Found in Baseline             : 2.3
Found Date                    : 12/29/93
Severity                      : C
Priority                      : 2
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[zeliff 12/29/93 public]

When bdiff is invoked:
  gemini src/rat_test$ bdiff -r 1.1.8.2 -R 1.1.2.3 1.sh
  ===================================================================
  RCS file: ./rat_test/1.sh,v
  retrieving revision 1.1.8.2
  retrieving revision 1.1.2.3
  5,12d4
  < # Revision 1.1.4.2  1993/09/08  20:38:12  damon
  < #     merge testing
  < #     [1993/09/08  20:38:06  damon]
  < # 
  < # Revision 1.1.4.1  1993/09/08  20:37:03  damon
  < #     merge testing
  < #     [1993/09/08  20:36:57  damon]
  < # 
  16c8
  < # 
  ---
  > #
  22,28d13
  < 
  < bbb
  < ddd
  < EEE
  < fff
  < ggg
  < more witty comments
  diff -r1.1.8.2 -r1.1.2.3

The last line isn't necessary.

[damon 12/28/93 public]
This problem went away when the rcs was told to shut up. Of course, it no
longer prints revisions, but hey! :-) See CR 956.

[damon 12/29/93 public]
Passes 'bdiff simple' test which looks for particular output.


CR Number                     : 956
Short Description             : bdiff displays garbage rev number
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : zeliff (Rich Zeliff)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/29/93
Found in Baseline             : 2.3
Found Date                    : 12/29/93
Severity                      : B
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[zeliff 12/29/93 public]

gemini src/rat_test$ bdiff -r zeliff_scripts -R DCE1_0_3 1.sh
===================================================================
RCS file: ./rat_test/1.sh,v
retrieving revision 1.1.8.2
retrieving revision 5,12d4
                    ^^^^^^

This is the problem.  This doesn't happen, by the way, when you specify
absolute RCS revision numbers as the switch values.  E.g. "-r 1.1.8.2 -R
1.1.2.3' 

This is the tool version:
  gemini src/rat_test$ bdiff -version
  program :  bdiff
  release :  ODE 2.3.2
  libode  :  Tue Oct 12 17:45:49 EDT 1993

Here's the branch information for the file:
  gemini src/rat_test$ blog -b 1.sh
  
  RCS file: ./rat_test/1.sh,v
  Working file: 1.sh
  head: 1.1
  branch:
  locks:
  access list:
  symbolic names:
	  zeliff_scripts: 1.1.8
	  dce1_1_b0: 1.1.4.4
	  dce1_0_3ab1: 1.1.2.3
	  dce1_0_3b10: 1.1.2.3
	  dce1_0_3b9: 1.1.2.3
	  dce1_0_3b8: 1.1.2.3
	  dce1_0_3b7: 1.1.2.3
	  dce1_0_3b5: 1.1.2.3
	  dce1_0_3b6: 1.1.2.3
	  root_dce103: 1.1.7
	  damon_dce103: 1.1.6
	  damon_replicate: 1.1.5
	  DCE1_1I: 1.1.4
	  DCE1_0_3: 1.1.2.3
  comment leader: "NONE"
  keyword substitution: o
  total revisions: 15;    selected revisions: 4

[damon 12/28/93 public]
This problem went away when the rcs was told to shut up. Of course, it no
longer prints revisions, but hey! :-) ODE will be modified to print this
out itself.

[marty 1/05/94 public]
bdiff has been modified to print out the following:

> gemini src/rat_test$ bdiff -r zeliff_scripts -R DCE1_0_3 1.sh
> rat_test/1.sh
> Comparing revision 1.1.8.2 [zeliff_scrpts] with revision 1.1.2.3 [DCE1_0_3].

    <<standard diff stuff>>


> gemini src/rat_test$ bdiff -r 1.1.8.2 -R DCE1_0_3 1.sh
> rat_test/1.sh
> Comparing revision 1.1.8.2 with revision 1.1.2.3 [DCE1_0_3].

    <<standard diff stuff>>


> gemini src/rat_test$ bdiff -r zeliff_scripts -R 1.1.2.3 1.sh
> rat_test/1.sh
> Comparing revision 1.1.8.2 [zeliff_scripts] with revision 1.1.2.3.

    <<standard diff stuff>>



> gemini src/rat_test$ bdiff -r 1.1.8.2 -R 1.1.2.3 1.sh
> rat_test/1.sh
> Comparing revision 1.1.8.2 with revision 1.1.2.3.

    <<standard diff stuff>>


> gemini src/rat_test$ bdiff -b 1.sh 
> rat_test/1.sh
> Comparing the file in your sandbox with revision 1.1.2.3.

    <<standard diff stuff>>

[damon 1/6/94 public]
Passed 'bdiff simple', 'bdiff revision_option', and 'bdiff two_revisions'
tests.


CR Number                     : 955
Short Description             : bdiff should print branch labels
Defect or Enhancement?        : enh
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : zeliff (Rich Zeliff)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/29/93
Found in Baseline             : 2.3
Found Date                    : 12/29/93
Severity                      : E
Priority                      : 4
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : bdiff.c, sci.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[zeliff 12/29/93 public]
It would be nice if bdiff printed the labels of the branches upon which the
diffing is done.  E.g.:

gemini src/rat_test$ bdiff -r zeliff_scripts -R DCE1_0_3 1.sh
===================================================================
RCS file: ./rat_test/1.sh,v
retrieving revision 1.1.8.2  [zeliff_scripts]
retrieving revision 1.2.3.4  [DCE1_0_3]
< # Revision 1.1.4.2  1993/09/08  20:38:12  damon
< #     merge testing
< #     [1993/09/08  20:38:06  damon]
< # 
< # Revision 1.1.4.1  1993/09/08  20:37:03  damon
< #     merge testing
< #     [1993/09/08  20:36:57  damon]
< # 
16c8
< # 
---
> #
22,28d13
< 
< bbb
< ddd
< EEE
< fff
< ggg
< more witty comments

[marty 1/5/94 public]

bdiff has been modified to print out the following:

> gemini src/rat_test$ bdiff -r zeliff_scripts -R DCE1_0_3 1.sh
> rat_test/1.sh
> Comparing revision 1.1.8.2 [zeliff_scrpts] with revision 1.1.2.3 [DCE1_0_3].

    <<standard diff stuff>>


> gemini src/rat_test$ bdiff -r 1.1.8.2 -R DCE1_0_3 1.sh
> rat_test/1.sh
> Comparing revision 1.1.8.2 with revision 1.1.2.3 [DCE1_0_3].

    <<standard diff stuff>>


> gemini src/rat_test$ bdiff -r zeliff_scripts -R 1.1.2.3 1.sh
> rat_test/1.sh
> Comparing revision 1.1.8.2 [zeliff_scripts] with revision 1.1.2.3.

    <<standard diff stuff>>



> gemini src/rat_test$ bdiff -r 1.1.8.2 -R 1.1.2.3 1.sh
> rat_test/1.sh
> Comparing revision 1.1.8.2 with revision 1.1.2.3.

    <<standard diff stuff>>


> gemini src/rat_test$ bdiff -b 1.sh
> rat_test/1.sh
> Comparing the file in your sandbox with revision 1.1.2.3.

    <<standard diff stuff>>

[zeliff 1/5/94 public]
How about printing labels even when a label isn't specified on the command
line.  For example, 'bdiff -b' is a case in which this would be very
helpful.

[marty 1/5/94 public]
I can put this in, but, you would be adding some overhead that you may not want.  Specifically,
for each file being diff'ed, I'd have to do a stat on each label in the checkout_config
string ("DCE1_0_3A;DCE1_0_3;DCE1_0_2;DCE1_0_1;") until I found the one that is the right one.
The code is easy to add, but with a lot of files, there would be a lot more RCS 'stat' commands
going back and forth between the clients and servers.  You people can decide amongst yourselves 
whether ot not you want this.

[zeliff 1/5/94 public]
I don't understand why this is so.  If you've done the diff then you know
what revisions you used -- all I'm looking for is the symbolic label
associated with the revision number.

[damon 1/5/94 public]
If only it was that simple. :-) While it is true that the information is
in the system, there is only a loose linking between ODE and rcs and this
prevents the information from being easily accessible. What actually happens
is that you send out a request like:

rcsstat -r"FOO;BAR;SNAFU"

which returns something like:

1.6.6.6

and we then use that to diff against whatever other rev you want. To get
the part of the "FOO..." that matched we would need to change rcsstat.
Which we can do.

[zeliff 1/5/94 public]
Oh.

Nevermind.

Is there a defect to cover developing an API-based interface to RCS?  ;-)

[damon 1/5/94 public]
Actually... yes. CR 404! Includes juicy mail from rcs big-wigs!

[marty 1/17/94 public]
Time to call it a day on this one.  It's fixed!

[damon 1/21/94 public]
Passed 'bdiff rev_label' test.


CR Number                     : 954
Short Description             : bdiff assumptions
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : zeliff (Rich Zeliff)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/29/93
Found in Baseline             : 2.3
Found Date                    : 12/29/93
Severity                      : B
Priority                      : 1
Status                        : fix
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole), marty (Marty Lynch)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[zeliff 12/29/93 public]
I'd like to change bdiff's default behavior.  If a user has a private
branch of the file being bdiff'ed then the default bdiff operation should
be:
  bdiff -r <users_private_branch> -R <backing_build_default_set> file.c

where 'backing_build_default_set' would be the first branch from the
check_out_config chain for which a branch actually exists.

This means that if a file is checked out in the user's sandbox the default
bdiff would compare the user's version and the backing build version.

Currently, if bdiff is invoked with no arguements on a file which is
checked out in a user's sandbox it assumes a '-r <user_sandbox_branch>' but
does not specify a -R.  If you try to specify a -R on the invocation it
forces you to supply the -r, as well.

[damon 12/28/93 public]
I don't think we can change the default behaviour at this point. bdiff has
always compared your current version against your most recent check in. Or,
if you have not done a bci, then against the version that you bco'd.

If you want to compare against the backing build, do bdiff -b foo.c

If you want to compare the file in your sandbox against a particular version,
use bdiff -r <rev> foo.c and not bdiff -R <rev> foo.c

Perhaps this should be changed to a doc CR?

[zeliff 12/29/93 public]
Ah, in that case this is a defect.  I have done work on a private branch of
'1.sh' in my sandbox.  According to what you wrote, if I type 'bdiff 1.sh'
it should diff my private branch against the "parent" branch from which I
checked out the file.  Here's what actually happens:

  gemini src/rat_test$ bdiff 1.sh
  ===================================================================
  RCS file: ./rat_test/1.sh,v
  retrieving revision 1.1.8.3
  diff -r1.1.8.3 /u0/rcs_trees/dce/rcs/#odexm000670/1.sh
    
Here's the blog info:
  gemini src/rat_test$ blog 1.sh
  
  RCS file: ./rat_test/1.sh,v
  Working file: 1.sh
  head: 1.1
  branch:
  locks:
  access list:
  symbolic names:
	  zeliff_scripts: 1.1.8
	  dce1_1_b0: 1.1.4.4
	  dce1_0_3ab1: 1.1.2.3
	  dce1_0_3b10: 1.1.2.3
	  dce1_0_3b9: 1.1.2.3
	  dce1_0_3b8: 1.1.2.3
	  dce1_0_3b7: 1.1.2.3
	  dce1_0_3b5: 1.1.2.3
	  dce1_0_3b6: 1.1.2.3
	  root_dce103: 1.1.7
	  damon_dce103: 1.1.6
	  damon_replicate: 1.1.5
	  DCE1_1I: 1.1.4
	  DCE1_0_3: 1.1.2.3
  comment leader: "NONE"
  keyword substitution: o
  total revisions: 16;    selected revisions: 3
  description:
  1.1.8.1>1.1.4.4;1.1.7.1>1.1.2.3;1.1.6.1>1.1.2.2;1.1.5.1>1.1.2.2;1.1.4.1>1.1.2.2;1.1.2.1>1.1;
  ----------------------------
  revision 1.1.8.3
  date: 1993/12/29 15:30:28;  author: zeliff;  state: Exp;  lines: +0 -0
	  Test2
  ----------------------------
  revision 1.1.8.2
  date: 1993/12/29 15:12:09;  author: zeliff;  state: Exp;  lines: +0 -0
	  test
  ----------------------------
  revision 1.1.8.1
  date: 1993/12/29 15:12:00;  author: zeliff;  state: Exp;  lines: +28 -0
  *** Initial Branch Revision ***
  =============================================================================

Incidentally, the 'bdiff -b foo.c' doesn't work either.

  gemini src/rat_test$ bdiff -b 1.sh
  ===================================================================
  RCS file: ./rat_test/1.sh,v
  retrieving revision 1.1.4.4
  diff -r1.1.4.4 /u0/rcs_trees/dce/rcs/#odexm000693/1.sh
	

Also, your recommendation for comparing the file to a particular revision
doesn't work:

  gemini src/rat_test$ bdiff -r 1.1.4.4 1.sh
  ===================================================================
  RCS file: ./rat_test/1.sh,v
  retrieving revision 1.1.4.4
  diff -r1.1.4.4 /u0/rcs_trees/dce/rcs/#odexm000736/1.sh

[damon 3/4/94 public]
I'm not sure how this happened, but I can't reproduce the problems above and
the test suite works fine. We need to add a test case for 'bdiff -b' before this
can be closed.


CR Number                     : 952
Short Description             : resb dumps core.
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : yak (Yakov Burtov)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/28/93
Found in Baseline             : 2.3.3
Found Date                    : 12/28/93
Severity                      : A
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[yak 12/28/93 public]

resb in ODE 2.3.3 dumps core, if the are some problems with the sandbox name. 
Here is the log:

pmin4 /net/pmin4/usr/sandbox/sb/20f/src 124 > resb -sb 2.0f $MB/motif2.0f-o
fopen /rc_files/: No such file or directory
fopen /rc_files/: No such file or directory
Segmentation fault (core dumped)
pmin4 /net/pmin4/usr/sandbox/sb/20f/src 125 > df `which resb`
Filesystem                              512-blocks    Used   Avail Capacity  Mounted on
server5:/u5/release/ode2.3.3/at386_osf1     621808  325706  233922    58%    /usr/ode

When I fixed the name of the sandbox (20f), resb worked fine.

[damon 12/28/93 public]
This no longer dumps core in 2.3.4, but it does give some additional goofy
messages:

fopen /rc_files/: No such file or directory
fopen /rc_files/: No such file or directory
>> WARNING in resb:
>> old link, , could not be read.
>> FATAL ERROR in resb:
        unlink failed on current backing link: .

[damon 12/29/93 public]
Passed 'resb no_sb' test.


CR Number                     : 951
Short Description             : bsubmit of leaderless file from backing build fails
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/28/93
Found in Baseline             : 2.3
Found Date                    : 12/28/93
Severity                      : B
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : libode/history.c
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : test
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 12/28/93 public]

Trying to submit a file with a single revision, such as you have when
submitting from a backing build, you get:

ci warning: missing message for -m option

This is because create_leaderless_log() assumes that it should only look 
at logs from .2 up and doesn't include the log from .1 .

[damon 12/29/93 public]
Passed 'bsubmit shared_to_full' test.


CR Number                     : 950
Short Description             : bsubmit ignores -rc option
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/28/93
Found in Baseline             : 2.3
Found Date                    : 12/28/93
Severity                      : B
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : libode/sci.c
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : test
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 12/28/93 public]

bsubmit -rc /project/test/build/test_s/.sandboxrc ... produced:

Entering bsubmit
----------------
>> WARNING in current_sb:
>> could not access rc file, /project/test/users/ode_user/.sandboxrc, for reading.
>> FATAL ERROR in bsubmit:
>> Could not establish sandbox environment.

[damon 12/29/93 public]
Passed 'bsubmit shared_to_full' test.


CR Number                     : 949
Short Description             : wrong status & confusing bco message
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : bco
Reported by                   : rsalz (Richard Salz)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/28/93
Found in Baseline             : 2.3
Found Date                    : 12/28/93
Severity                      : B
Priority                      : 2
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[rsalz 12/28/93 public]

    ; bco -read lexl
    stat error: ./tools/sams/RCS/lexl,v: No such file or directory
>   must use numeric revision for check-out
>   ./tools/sams/lexl
Should exit with non-zero status and doesn't.
The two marked lines (>) should not appear; the last is particularly confusing.
The error message should be like the one shown below.

    ; bco lexl            
>   stat error: ./tools/sams/RCS/lexl,v: No such file or directory
    File ./tools/sams/lexl is not under source control.
>   ./tools/sams/lexl
Should exit with non-zero status and doesn't.
The two marked lines (>) should not appear; the last is particularly confusing.

The two error messages should be the same.

[damon 12/28/93 public]
The last line is now gone.

WARNING should be ERROR.

[damon 1/6/94 public]
Created test 'bco not_exists' which tests for correct output and non-zero
exit status.
Passed 'bco not_exists' test.


CR Number                     : 942
Short Description             : ODE needs VERROR for ui_print()
Defect or Enhancement?        : enh
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/27/93
Found in Baseline             : 2.3
Found Date                    : 12/27/93
Severity                      : B
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 12/27/93 public]

If there is a problem which causes termination of a program, that is a fatal
error, ui_print() uses VFATAL to indicate this. If Something happened which
the user should know about but does not impede progress, then the program
should issue a warning. This is what VWARN is for. However, if the user does
something or the program does something which is a correctable error and does
not lead to program termination, then there is no appropriate ui_print() value.

VERROR should be added for this condition.

[alan 12/27/93 public]
An uncorrected error (correct*able* or not) would be a VERROR.
However, a corrected error is a VWARN (e.g. 'mksb: No
$(HOME)/.sandboxrc; creating one with this sandbox as default').
Therefore, "If Something happened which the user should know about but
does not impede progress", the program should use VWARN.

[damon 12/27/93 public]
Hmm. Let me try that again. :-). People have the impression ( which is fine )
that a warning is as you have stated above. However, there are errors that
occur that don't need the stigma of being _fatal_. For instance, if a file
is writable and you try to check it out, that is an error. But, is it a 
FATAL ERROR? I think FATAL ERROR should be reserved for abnormal terminations.
In other words, there is to much of a leap between warning and fatal error.
I think there needs to be something in between.

[damon 12/31/93 public]
VERROR is used by at least bco and this is shown in the test 'bco bad_rev'.


CR Number                     : 938
Short Description             : bci of file with garbage comment leader hic-ups 'odexm'.
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : gupta
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/22/93
Found in Baseline             : 2.3
Found Date                    : 12/22/93
Severity                      : C
Priority                      : 3
Status                        : dup
Duplicate Of                  : 919
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : ode/lib/libode/sci.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[gupta 12/22/93 public]

I have a file "README" that was inadvertently given the comment leader
"#" instead of "# ".  When I 'bci' this file I get the message:

>> WARNING in bci:
>> Comment leader must end with space.
>> File: ./usr/ccs/lib/rtld/test/diamond/README.
>> Comment leader: '#'.
odexm: read needsecret failed: No such file or directory

The 'odexm' message should not be there.  Also, it just so happens
that when 'bci'ing many files, the next file (after getting the odexm message)
hangs on 'bci'.

[marty 12/22/93 public]
This is a duplicate of CR # 919.  The code in sci_get_comment_leader()
was leaving odexm connections open (when invalid comment leaders were 
detected) and thus locking up the sandbox.


CR Number                     : 934
Short Description             : bco warning is really an error
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : bco
Reported by                   : rsalz (Richard Salz)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/20/93
Found in Baseline             : 2.3
Found Date                    : 12/20/93
Severity                      : A
Priority                      : 0
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[rsalz 12/20/93 public]
	; touch svcacl.h
	; bco svcacl.h
	>> WARNING in bco:
	>> File ./dce/utils/svc/svcacl.h is writeable, indicating that it has
	>> been changed since it was checked out.
	./dce/utils/svc/svcacl.h
	; ls -l svcacl.h
	-rw-rw-r--   1 rsalz    osf            0 Dec 20 15:49 svcacl.h

This is *not* a warning, it is an error:  bco did *not* check out the file.

This is not what RCS does, and it really REALLY confuses the programmer
into thinking that he is editing the latest file, only to be sadly
enlightened when s/he tries to do bci.

[marty 12/21/93 public]
Rich,

   I changed the message to print the following:

        ; bco svcacl.h   (multiple "bco's")

        ; bco svcacl.h
	>> FATAL ERROR in bco:
	>> File ./....../svcacl.h is writeable.
	>> Check out will not be performed for this file.

   Or, if the file is not in the current set (but is writable):

        ; touch svcacl.h
        ; bco svcacl.h
	>> FATAL ERROR in bco:
	>> File ./...../avcacl.h is writeable.
	>> This file is not part of the current set marty_odedev.
	>> Check out will not be performed for this file.

[damon 12/29/93 public]
Changed FATAL ERROR to new level: ERROR.
Passed 'bco bco_after_bco' test.


CR Number                     : 932
Short Description             : bco silently overwrites writeable files
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : bco
Reported by                   : rsalz (Richard Salz)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/20/93
Found in Baseline             : 2.3
Found Date                    : 12/20/93
Severity                      : A
Priority                      : 0
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : lib/libode/sci.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[rsalz 12/20/93 public]

bco doesn't confirm before clobbering writeable files.  RCS does.

[marty 12/21/93 public]
Rich,
   I changed "bco -read" to give the following message if a writable file
already exists:

% touch foo.c
% ./bco -read foo.c
>> FATAL ERROR in bco:
>> File ./ode/bin/bco/foo.c is writeable.
>> This file may already be checked out for editing.
>> Check out read-only will not be performed for this file.

[damon 12/29/93 public]
Passed 'bco bco_after_bco' test.


CR Number                     : 929
Short Description             : mklinks removes a character in pathname when path to sandbox is through a link.
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : marty (Marty Lynch)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/17/93
Found in Baseline             : 2.3
Found Date                    : 12/17/93
Severity                      : A
Priority                      : 0
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : ode/bin/mklinks/mklinks.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[marty 12/17/93 public]

[marty 12/17/93 public]
Fixed

[damon 1/27/94 public]
Passed 'mklinks link_in_sb_path' test.


CR Number                     : 928
Short Description             : regression: bsubmit gives unexpected eof if merge required
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/17/93
Found in Baseline             : 2.3.4
Found Date                    : 12/17/93
Severity                      : A
Priority                      : 0
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : test
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 12/17/93 public]
If a merge is required during bsubmit, bsubmit complains:

Abort, ok, edit, merge, rco, co,
rdiff, diff, leader  [ok]  
Unexpected end of file
>> WARNING in bsubmit:
>> Improper markers or history section in file ./rat_test/try.c

etc.

Using a pre ode2.3.4 bsubmit works fine.

[damon 12/27/93 public]
bsubmit's call to sci_copyright_init() simply needed a '&' removed.

[damon 12/29/93 public]
Passed 'bsubmit merge' test.


CR Number                     : 925
Short Description             : bmerge should complain if rev not found
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : bill (Bill Masek), alan (Alan Hamilton)
Reported Date                 : 12/17/93
Found in Baseline             : 2.3
Found Date                    : 12/17/93
Severity                      : B
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : bmerge.c, sci.h, sci.c
Responsible Engr.             : 
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : handson
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 12/17/93 public]
bmerge -common OSC1.2.MAINT -r 3.0.2.3 thread.c

produces:
No merges required.

when it should produce:
No match for revision 'OSC1.2.MAINT'

The correct label is OSC1_2_MAINT .

[marty 1/18/94 public]
Changed bmerge to handle the following two cases.

-  If the user specifies a revision to merge to (-r 3.0.2.3) and that
revision does not exist then the following message is printed.

bmerge  -r 3.0.2.3 Makefile 
>> ERROR in bmerge:
>> File ./ode/bin/bmerge/Makefile does not have revision '3.0.2.3'.  
>> Cannot merge revisions.
No merges required.

-  If the user specifies a revision as a common ancestor 
(-common 3.0.2.3) and that revision does not exist then the following message 
is printed.

bmerge  -common 3.0.2.3 Makefile 
>> ERROR in bmerge:
>> File ./ode/bin/bmerge/Makefile does not have revision '3.0.2.3'.
>> Cannot merge revisions.
No merges required.


If this were to happen to one file out of a list of files 
then the message above  is printed (as you would expect), the 
file is weeded out of the list of files to process, and the 
merge continues for the rest of the files.

[damon 1/21/94 public]
Passed 'bmerge no_rev' test.


CR Number                     : 923
Short Description             : bsubmit should not print full name when -auto and/or -fn used
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/16/93
Found in Baseline             : 2.3
Found Date                    : 12/16/93
Severity                      : E
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : ode/bin/bsubmit/bsubmit.c
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : test
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 12/16/93 public]

bsubmit always prints out:

Full name for the log: Dev Admin

even though it only needs to do this if this is a query and not if it has
the information and has been given the -auto and/or -fn switches.

[damon 12/29/93 public]
Passed 'bsubmit simple' test.


CR Number                     : 922
Short Description             : bco -undo gives no info if no user branches exist
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/16/93
Found in Baseline             : 2.3
Found Date                    : 12/16/93
Severity                      : D
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : ode/bin/bco/bco.c
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : test
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 12/16/93 public]

If you run bco -undo on a file that you don't have checked out, the command
just returns to the prompt without informing you that nothing was done
because there was nothing to do.

[damon 12/29/93 public]
Passed 'bco undo_no_user_branch' test.


CR Number                     : 921
Short Description             : bcreate -undo of bci'd file gives internal error
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/16/93
Found in Baseline             : 2.3
Found Date                    : 12/16/93
Severity                      : C
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : ode/include/errno.h,ode/lib/libode/error.c,ode/lib/libode/src_ctl_rcs.c
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : test
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 12/16/93 public]

%bcreate foo.c
%bci foo.c
%bcreate -undo foo.c

gives:

>> FATAL ERROR in bcreate:
>> [ should not undo revision 1.1.1.2 -- try bco -undo ]
Internal error

The first two lines of the resulting output are fine, the internal error
should not come up.

[damon 12/16/93 public]
Added BADUNDOREV ode errno.

[damon 12/29/93 public]
Passed 'bcreate undo_checked_in' test.


CR Number                     : 920
Short Description             : bcreating already bcreated files prints misleading message
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/16/93
Found in Baseline             : 2.3
Found Date                    : 12/16/93
Severity                      : C
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : ode/lib/libode/sci.c
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : test
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 12/16/93 public]

bcreating an already bcreated file produces:

File ./Makefile is already under source control.
./Makefile created.

Only the first message should be printed out.

[damon 12/29/93 public]
Passed 'bcreate already_exists' test.


CR Number                     : 919
Short Description             : bci fails & odexm locks sandbox
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : robert (Rob Dicamillo)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/16/93
Found in Baseline             : 2.3
Found Date                    : 12/16/93
Severity                      : B
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : lib/libode/sci.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[robert 12/16/93 public]

For this user running ksh, bci apparently thinks that
parsing multiple <pathname>/<file> args that begin with "./" is cause
for a comment leader error. That is the contents of the file used below
to provide args to bci , "/tmp/lll", contains multiple <pathname>/<file>
entries which all beginning with "./".  Yet when you remove the leading "./", 
bci works OK.  (Hence the output from find to create lists of files for users
to process can no longer be used directly - ouch). 

There might be a problem that the user has something funny set up
in his ksh, but I have not been able to find anything in his
environment.

This error from bci causes odexm to return with a by now famously cryptic
error message "odexm: request for secret: No such file or directory". 
This kind of message is even *more* cryptic then the error messages that 
for example, the kerberos code used to return when it was used in older 
versions of ode.  Users have absolutely no idea of what this kind of
"secret" message means and frankly it just makes them more frustrated with 
ode's user interface to see text they cannot be expected to comprehend; 
this kind of message should probably be part of -debug or -verbsoe info. 

Once odexm locks the sandbox, the .BCSlock file must be removed 
in order to do any further sandbox operations; simply moving the lock file to 
a tmp file and back does not break the lock.  However, while the lock is
active and even with running other b-cmds with -verbose, -debug, or setting 
AUTHCOVER_DEBUG - there is no real information that readily points to having to 
remove .BCSlock. The error messsage displayed "[ Waiting for sandbox lock ]" 
is utterly non self-diagnosing (and the poor user can't normally see his lock 
file anyway because it's a "." file). 
  
This questionable parsing of "./" is reminiscent of a bug where  mklinks 
parses argument that begin with "./" in a brain dead kind of way.
(Args to -link_from and -link_to  beginning with "./" cause
mklinks to include redundant  "/" and "." in it's path or 
foo.c@ -> /project/osc/build/osc1.3/src//././foo.c).

Overall, this kind of behavior in the 2.3 user interface is just making 
users wish more and more that the RI never switched - they liked the 2.1.1 
interface better.

Here is the output, where I have added comments in between "****"

**** first bci ***
 
/afs/ri/user/travos > workon -sb xkxk
cd'ing to sandbox source directory: /afs/ri/user/travos/sb/xkxk/src.
project: osc
starting new shell: /usr/bin/ksh.
/afs/ri/project/sb/travos/xkxk/src > bci -m "Created" -auto `cat /tmp/lll`
>> WARNING in bci:
>> Comment leader must end with space.
>> File: ./xkern/protocols/bidctl/bidctl_i.h.
>> Comment leader: '*'.
/afs/ri/project/sb/travos/xkxk/src > odexm: request for secret: No such file ordirectory

*** the sandbox is now locked - now the user tries bci again ***

/afs/ri/project/sb/travos/xkxk/src > r bci
bci -m "Created" -auto `cat /tmp/lll`
[ Waiting for sandbox lock ]

*** this user is now utterly hung! If he even figures out he has to ***
*** remove .BCSLock, he will recreate the problem again with another bci ***

[marty 12/16/93 public]

Robert,
   I think there are two problems here:

1)  The following message means that you have a comment leader set to "*" instead of " * ":

>> WARNING in bci:
>> Comment leader must end with space.
>> File: ./xkern/protocols/bidctl/bidctl_i.h.
>> Comment leader: '*'.

To get around this problem you must properly set the comment leader on these files.
   
2)  I'm not sure why you are getting the 
"odexm: request for secret: No such file ordirectory" message but it looks like
a problem with your server.  I'll look into it further.

Also, please remember that we have just fixed the "././." in pathname problem created
by mklinks.  This fix is in ode2.3.4.  

Later!

[marty 12/22/93 public]
Roberto,
  Well, it seems as though you've stumble on a small but nasty bug.  This
problem stems from the fact that the routine sci_get_comment_leader() can
(in the case of invalid comment leaders) leave an odexm connection open
on your machine.  Since this connection is done via a process that happens
to also have your sandbox locked, guess what, you can't do anything more 
with your sandbox until you kill of a few background processes. 

  There is a simple fix for this that'l go into ode2.3.4.  If you need a new 
version of bci sooner, let me know.

[damon 1/21/94 public]
Passed 'bci bad_leader' test.


CR Number                     : 918
Short Description             : bmerge updates files unnecessarily
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/16/93
Found in Baseline             : 2.3
Found Date                    : 12/16/93
Severity                      : D
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : test
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 12/16/93 public]
bmerge updates the ancestry and ci's files that don't require merging. This
doesn't hurt anything, but it clutters the ancestry information and the
history log. It also slows down merging of multiple files.

[damon 12/16/93 public]
Added function sci_select_need_merge() so that bmerge will handle only
files that truly need merging.

[damon 1/21/94 public]
Passed 'bmerge no_merge' test.


CR Number                     : 915
Short Description             : bdiff doesn't print file names
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/16/93
Found in Baseline             : 2.3
Found Date                    : 12/16/93
Severity                      : D
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : test
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 12/16/93 public]
Given a list of files to diff, bdiff just prints the results and does not
print the names of the files as they are diffed. This is a result of telling
rcs to be quiet.

[damon 12/29/93 public]
Passed 'bdiff simple' test.


CR Number                     : 914
Short Description             : bci no longer printing file names if -auto is used
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/15/93
Found in Baseline             : 2.3
Found Date                    : 12/15/93
Severity                      : B
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : ode/lib/libode/sci.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : test
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 12/15/93 public]

[marty/12/15/93 public]
Fixed.

[damon 12/29/93 public]
Passed 'bci simple' test.


CR Number                     : 908
Short Description             : mksb 2.3.3 dumps core on alpha
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : mksb
Reported by                   : dsb (David Boyce)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/10/93
Found in Baseline             : 2.3
Found Date                    : 12/10/93
Severity                      : B
Priority                      : 2
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : ode/bin/mksb/mksb.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[dsb 12/10/93 public]

I tried to run mksb on presto with the following result:

dsb@presto 0 7> mksb 64native
Segmentation fault(coredump)
dsb@presto 139 8> rm core
dsb@presto 0 9>    
dsb@presto 0 9> mksb -version
program :  mksb
release :  ODE 2.3.3
libode  :  Tue Nov 16 14:48:17 EST 1993

[marty 12/14/93 public]
Just needed to initialize a few variables.  Seems as though on ALPHA
it is pretty important, where other platforms don' care.

[damon 2/24/94 public]
Passed all mksb tests on alpha (presto!).


CR Number                     : 906
Short Description             : rcs 5.6 still has BIN problems!!
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : pmax
S/W Ref Platform              : ultrix
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/10/93
Found in Baseline             : 2.3
Found Date                    : 12/10/93
Severity                      : A
Priority                      : 0
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : test
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 12/10/93 public]
Aaaaaaaaaaaaarg! In ODE, binary files use the comment leader BIN to indicate
that they are binary. In addition, ODE tells rcs to use expand mode -ko with
binary files which is supposed to leave them untouched. This works except for
the fact that rcs gratuitously appends a single (char)64 to the end of the file.
This only seems to happen on pmax_ultrix, but since that is the context for
the machine that the test suite is being submitted to and the test suite has
lots of binary files and this problem is holding up work on the test suite
and the test suite has to be finished before 2.3.4...

[damon 12/12/93 public]
Boy is this complicated! The problem occurs when -ko is used on pmax_ultrix,
and the setup is the typical ODE rcs file and the file doesn't have a newline
at the end. For instance:

%touch a
%ci a
%touch a
%ci -f -r1.1.1 a
%co -l1.1.1 a
[remove a and replace with a file with no newline at the end of the file]
%ci -u1.1.1 a
%co -u1.1.1 a

The resulting file will have an extra '@' on the end of it.

Also, if the mode is anything but -ko, there is no problem. But, we have to
use -ko so that if keywords appear in the binary file, they won't be expanded.

[damon 12/13/93 public]
Actually, this is an rcs CR and not and ODE CR, so it is fixed in rcs5.6, not
ODE 2.3.4. This problem was due to a logic error in rcsedit.c which had
some code for SDELIM in the wrong place.

[damon 1/21/94 public]
Passed 'bcreate simple' test.


CR Number                     : 904
Short Description             : mklinks does not use mkdir -p?
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : mklinks
Reported by                   : dsb (David Boyce)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/10/93
Found in Baseline             : 2.3
Found Date                    : 12/10/93
Severity                      : C
Priority                      : 2
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : ode/bin/mklinks/mklinks.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[dsb 12/10/93 public]

The following command does not work:

dsb@ets7 0 6> cd $SOURCEBASE
dsb@ets7 1 7> mklinks sbin/cfgmgr

but if I "mkdir sbin" and "cd sbin", then

dsb@ets7 1 7> mklinks cfgmgr

works fine.  It has the appearance of a missing -p flag to mkdir,
but that's just a guess.  This used to work fine in ODE 2.1.

[marty 12/14/93 public]
'mklinks' now does the equivalent of `mkdir -p` on the directories
leading up to the target directory.

[damon 1/18/94 public]
Passed 'mklinks subdir' test.


CR Number                     : 902
Short Description             : bcreate dumps core if it doesn't like copyrights file.
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : yak (Yakov Burtov)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/9/93
Found in Baseline             : 2.3
Found Date                    : 12/9/93
Severity                      : A
Priority                      : 3
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : ode/lib/libode/copyrights.c,bin/bcreate/bcreate.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[yak 12/9/93 public]

bcreate -undo dumps core if the first line in the copyrights file isn't
COPYRIGHT NOTICE

Here is the log:
pmin4 /net/pmin4/u1/sand/doc20/src/rat_test/yakov 52 > bcreate -undo test.3
>> FATAL ERROR in bcreate:
>> First line in copyrights file must be COPYRIGHT NOTICE
Internal error
Segmentation fault (core dumped)
pmin4 /net/pmin4/u1/sand/doc20/src/rat_test/yakov 53 > 

Sandbox was made against motif2.0doc tree, and the rc_files/motif/copyright
file has the following:
Copyright (c) @YEARS@ Open Software Foundation, Inc.
ALL RIGHTS RESERVED (MOTIF). See the file named COPY.MOTIF.DOC for
the full copyright text.

bcreate without -undo goes in infinitive loop in this case:
pmin4 /net/pmin4/u1/sand/doc20/src/rat_test/yakov 53 > bcreate aaa.c
>> FATAL ERROR in bcreate:
>> First line in copyrights file must be COPYRIGHT NOTICE
Internal error
Copyright name DEFAULT is not legal.
Please choose one of the following copyright names:
> 
Copyright name  is not legal.
Please choose one of the following copyright names:
> COPYRIGHT NOTICE
Copyright name COPYRIGHT NOTICE is not legal.
Please choose one of the following copyright names:
> Copyright name COPYRIGHT NOTICE is not legal.
Please choose one of the following copyright names:
>  
Copyright name   is not legal.
Please choose one of the following copyright names:
> Copyright name   is not legal.
Please choose one of the following copyright names:
> pmin4 /net/pmin4/u1/sand/doc20/src/rat_test/yakov 54 >

[marty 12/14/93 public]
Both problems fixed.

[damon 1/18/94 public]
Same problems exist without -undo.
Passed 'bcreate bad_copyright' test.


CR Number                     : 900
Short Description             : bco error message garbled
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : jph (James Pitcairn-Hill)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/8/93
Found in Baseline             : 2.3
Found Date                    : 12/8/93
Severity                      : D
Priority                      : 3
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : src/ode/lib/libode/sci.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[jph 12/8/93 public]
In a sandbox backed by /project/osc/build/osc1.3

	% cd mach_kernel/vm
	% bco -read -r 1.3.30.2 memory_object.c
	>> WARNING in bco:
	>> File does not contain the revision specified. 
	>> File: ./mach_kernel/vm/memory_object.c
	>> Revision: 1.3.30.2
	Revision D of file '1.3.30.2' does not exist

Note the crufty revision and file mix-up. As to why it thinks this revision
number doesn't exist (the number is in the log) I haven't the foggiest...

[marty 12/8/93 public]
Fixed.  The routine that creates files was calling an error reporting
routine with the wrong number of arguments.

[damon 12/30/93 public]
Passed 'bco bad_rev' test.


CR Number                     : 899
Short Description             : bsubmit -info does update when merge is required
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : robert (Rob Dicamillo)
Reported Date                 : 12/8/93
Found in Baseline             : 2.3
Found Date                    : 12/8/93
Severity                      : C
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 12/8/93 public]
When a merge is required and bsubmit -info is run, the ancestry is updated!!

[damon 1/19/94 public]
Added test 'bsubmit info_merge'. Fails as expected.

[damon 1/19/94 public]
Test for ui_is_info() for merges.
Passed 'bsubmit info_merge' test.


CR Number                     : 897
Short Description             : bci -all is not informative
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : sp (Simon Patience)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/8/93
Found in Baseline             : 2.3
Found Date                    : 12/8/93
Severity                      : C
Priority                      : 3
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : ode/lib/libode/sci.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[sp 12/8/93 public]
When using bci -all, but not in auto mode, bci does not tell you the
name of the file it is dealing with when it prompts
[ Please create a log message describing your changes ]
Command? (type "help" for a list)  [log] 
It rather difficult to know what to do if you don't know the file name.
bci used to print the file name in this situation before the prompt.

[marty 12/8/83 public]
Fixed.  'bci -all' now prints the name of the file being operated on
before the  "Command? (type "help" for a list)  [xxx]" prompt.  This
was fixed as part of the work done to put the "-xlog" switch back in
'bci'.  It'll be in ode2.3.4.

[damon 12/30/93 public]
Passed 'bci no_auto' test.


CR Number                     : 896
Short Description             : logdiff not abbreviated
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : sp (Simon Patience)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/8/93
Found in Baseline             : 2.3
Found Date                    : 12/8/93
Severity                      : C
Priority                      : 3
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : ode/lib/lobode/stablk.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[sp 12/8/93 public]
When using bci, you get the prompt
Command? (type "help" for a list)  [log]  
In previous versions of ode, you could type any abbreviation of logdiff
as long as it was distinguishable from plain 'log'. This meant any of
logdiff, logdif, logdi or logd would cause the same action. Now, all
of these except the full logdiff are synonymous with 'log', which 
doesn't make much sense to me, to say nothing of causing extra 
unnecessary typing.

[marty 12/8/93 public]
This was fixed along with the work to add "-xlog" back into
'bci'.  It'll be in ode2.3.4.

[damon 12/30/93 public]
Passed 'bci logdiff' test.


CR Number                     : 895
Short Description             : ./ interpreted by ODE as /
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : robert (Rob Dicamillo)
Reported Date                 : 12/8/93
Found in Baseline             : 2.3
Found Date                    : 12/8/93
Severity                      : C
Priority                      : 2
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 12/8/93 public]

[damon 12/29/93 public]
Added ./ and / to file names in test 'bstat bcreated'.
Passed 'bstat bcreated' test.


CR Number                     : 888
Short Description             : resb considered harmful
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : drk (David Kaelbling)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/3/93
Found in Baseline             : 2.3
Found Date                    : 12/3/93
Severity                      : C
Priority                      : 3
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[drk 12/3/93 public]

I invoked "resb" with no parameters.  My sandbox was left in a broken
state.

[motif2_0] 97> resb
>> FATAL ERROR in resb:
>> returning sandbox to its original state.
>> WARNING in resb:
>> could not restore /users/drk/sandboxes/motif2_0/link to /project/motif/build/motif2.0b-s.
>> FATAL ERROR in resb:
        failed to link to backing tree
  (null)->/users/drk/sandboxes/motif2_0/link.
WARNING: you must create this link manually to continue.

[motif2_0] 98> resb /project/motif/build/motif2.0b-h.s
>> WARNING in resb:
>> old link, /users/drk/sandboxes/motif2_0/link, could not be read.
>> FATAL ERROR in resb:
        unlink failed on current backing link: /users/drk/sandboxes/motif2_0/lik.

[damon 12/3/93 public]
When I run resb with no parameters I get:

--cut--
>> FATAL ERROR in resb:
        Must include name of backing tree to retarget to.
USAGE:
resb new-backing-tree [sb_opts]
     new-backing-tree: the sandbox or build to be backed by.
     sb_opts:
       [-sb <sandbox>, -rc <rc_file>, -sb_rc <sb_rcfile>]
--cut--

I am not sure how the first part of the sequence above happened. What
version of resb? Is there an entry for resb in the .sandboxrc file?

resb -version
grep resb ~/.sandboxrc

[drk 12/3/93 public]

[motif2_0] 6> resb -version
program :  resb
release :  ODE 2.3.2
libode  :  Tue Oct 12 17:45:49 EDT 1993

[motif2_0] 7> grep resb ~/.sandboxrc

[damon 2/1/94 public]
I don't think this is a problem anymore, but we need to add a case to the
test suite anyway. I have reduced the severity since the workaround is to
manually do the resb. Redo the link and edit the backing_project in the
sb.conf file.

[damon 2/2/94 public]
It turns out that this problem shows up when a project is not using the
build environment. I moved the code that checks for a backing build outside
of the build environment conditional code.

Passed 'resb no_build' test.


CR Number                     : 886
Short Description             : remove unecessary printf of common ancestor
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : jeffc (Jeff Carter)
Reported Date                 : 12/3/93
Found in Baseline             : 2.3
Found Date                    : 12/3/93
Severity                      : E
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 12/3/93 public]
src_ctl_prep_merge() has some old baggage:

  if ( sci_ptr -> same23) {
    ui_print ( VALWAYS, "base revision %s\n", rev2);
    ui_print ( VALWAYS, "common ancestor %s; will just use revision %s\n",
       rev3, rev1);
    ui_print ( VALWAYS, "No merge required\n", rev3 );
    sci_ptr -> ver_ancestor = strdup ( rev3 );
    if ( sci_ptr -> ver_ancestor == NULL ) {
      ui_print ( VFATAL, "strdup failed\n" );
      return ( ERROR );
    }
    return( OK );
  }

That should just be:

  if ( sci_ptr -> same23) {
    sci_ptr -> ver_ancestor = strdup ( rev3 );
    if ( sci_ptr -> ver_ancestor == NULL ) {
      ui_print ( VFATAL, "strdup failed\n" );
      return ( ERROR );
    }
    return( OK );
  }

[jeffc 12/3/93 public]
Don't forget that this changes the visible behavior of this routine
for all the _other_ callers, like bmerge. This printf is used to notify
the user of an important bit of status when  you are merging the contents
of one branch onto another.

[damon 12/3/93 public]
Luckily, in this case, this message is extra. In other words, the routines
calling this routine will print out the merge info as needed. The next
section of code has already had the extraneous printfs removed. The ones
that are still there just got missed. Probably because that section is not
often executed.

  if ( sci_ptr -> same13) {
    sci_ptr -> ver_ancestor = strdup ( rev3 );
    (void) unlink(temp1);
    return( OK );
  }

[damon 1/21/94 public]
Passed 'bsubmit simple' test.


CR Number                     : 884
Short Description             : merging still prints rcs info
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/2/93
Found in Baseline             : 2.3
Found Date                    : 12/2/93
Severity                      : E
Priority                      : 0
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : test
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 12/2/93 public]
The rcs info, which includes odexm temp files, makes it difficult to do
testing.

[damon 1/4/93 public]
Although most of the rcs info is gone, some is still printed when the
ancestry information is updated.

[damon 1/4/93 public]
Passed 'bmerge merge' test.


CR Number                     : 883
Short Description             : bdelta not built for ODE2.3
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : marty (Marty Lynch)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/2/93
Found in Baseline             : 2.3
Found Date                    : 12/2/93
Severity                      : A
Priority                      : 2
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : ode/custom_tools/bdelta.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[marty 12/2/93 public]
Changes have been submitted.

[damon 1/28/94 public]
bdelta is not in the test suite as it is not part of the 'regular' ODE, but it
has been in use without complaint so I am closing this.


CR Number                     : 882
Short Description             : bstat -a fails when ancestor is not direct
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : jeffc (Jeff Carter)
Reported Date                 : 12/2/93
Found in Baseline             : 2.3
Found Date                    : 12/2/93
Severity                      : B
Priority                      : 0
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.3,2.3.4
Fixed In Baseline             : 2.3.3,2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 12/2/93 public]
When looking up ancestry was separated from looking up ancestors, bstat
was forgotten. bstat needs to make a call to sci_lookup_ancestry_list().

[damon 12/2/93 public]
There was also a strcmp() on a NULL value.

[damon 12/30/93 public]
Passed 'bstat ancestors' test.


CR Number                     : 880
Short Description             : bcreate -undo still prints rcs info
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/2/93
Found in Baseline             : 2.3
Found Date                    : 12/2/93
Severity                      : E
Priority                      : 0
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : test
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 12/2/93 public]
The rcs info is coming back from the server at different times and making
testing difficult.

[damon 12/29/93 public]
Passed 'bcreate undo' test.


CR Number                     : 876
Short Description             : mklinks od's on "." and "/"
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : robert (Rob Dicamillo)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/1/93
Found in Baseline             : 2.3
Found Date                    : 12/1/93
Severity                      : C
Priority                      : 1
Status                        : fix
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : ode/bin/mklinks/mklinks.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[robert 12/1/93 public]

91 % pwd
/afs/ri/project/kernel/build/ad2_latest
92 % mklinks -link_from /afs/ri/project/kernel/build/ad2_latest/link/src -link_to ./src

Linking:
  From: /afs/ri/project/kernel/build/ad2_latest/link/src
  To:   ./src

is this correct?  [yes]
93 % ls
MMAX/            copyright_note@  etc/             osf1_server/     stand/
Makeconf@        default_pager/   kernel/          rat_test/        tcb/
Makefile@        defunct.csh      kxct.conf        rc_files/        usr/
PMAX/            defunct.log      mach_kernel/     sbin/
README@          defunct_rm.csh   mach_services/   seccmd/
bootstrap/       dev/             mon.out@         setup/
94 % ls -ld Makefile
lrwxr-xr-x   1 devrcs   system               62 Dec  1 12:18 Makefile@ -> /afs/ri/project/kernel/build/ad2_latest/link/src//././Makefile

can't parsing be fixed so that "././" is not necessary ?

[marty 12/14/93 public]
Roberto,  this has been fixed.  All pathnames passed to mklinks are now
canonicalized.


CR Number                     : 875
Short Description             : _LOG_ file left in sandbox tmp dir
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 12/1/93
Found in Baseline             : 2.3
Found Date                    : 12/1/93
Severity                      : E
Priority                      : 4
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : lib/libode/sci.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : test
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 12/1/93 public]

[marty 12/2/93 public]
Fixed!

[damon 1/4/94 public]
I'm not sure which command this initially referred to, but bci is still (now?)
doing this.

Test failed: "bci simple".

[marty 1/05/94 public]
Fixed.  sci_check_in_list2() has been changed to remove the _LOG_ file
when finished processing the file list.

[damon 1/6/94 public]
Passed 'bci simple' test.


CR Number                     : 871
Short Description             : bcreate does not always set expansion mode correctly
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 11/30/93
Found in Baseline             : 2.3
Found Date                    : 11/30/93
Severity                      : B
Priority                      : 0
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : ode/lib/libode/sci.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : test
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 11/30/93 public]
For NONE and BIN, the expansion mode should be set using rcs -ko just
like bcs -c. This is not currently happening.

[marty 12/1/93 public]
It's fixed now.

[damon 12/29/93 public]
Passed 'bcreate simple' test.


CR Number                     : 867
Short Description             : bsubmit too picky during validation
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : robert (Rob Dicamillo)
Reported Date                 : 11/29/93
Found in Baseline             : 2.3
Found Date                    : 11/29/93
Severity                      : B
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.3,2.3.4
Fixed In Baseline             : 2.3.3,2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 11/29/93 public]
bsubmitting from a shared sandbox does not work if the file being submitted has
only been submitted to the shared sandbox once. This is because the tip
revision for the branch is .1 whereas bsubmit wants it to be .2 or higher.
This check can be removed since bsubmit checks the read/write permissions of
the file to see if the file has been checked in.

[damon 12/29/93 public]
Passed 'bsubmit shared_to_full' test.


CR Number                     : 865
Short Description             : separate copyright/history broken
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 716
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : alan (Alan Hamilton)
Reported by Company           : osf
Interest List CC              : meissner (Michael Meissner), duthie (Kathy Duthie), kirschen (David Kirschen), boot (Bruce Bauman), collison, smk (Stephen Kafka)
Reported Date                 : 11/24/93
Found in Baseline             : 2.3
Found Date                    : 11/24/93
Severity                      : A
Priority                      : 0
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.3,2.3.4
Fixed In Baseline             : 2.3.3,2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : handson
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[alan 11/24/93 public]

Damon Poole <damon@osf.org> wrote:

> I think the behaviour of copyright checking must have changed. I'll
> look into it further, but I believe that bci/bsubmit no longer like:
> 
> # @OSF_FREE_COPYRIGHT@
> 
> test
>  
> # HISTORY
> # $Log: change_requests,v $
NONERevision 1.1.7.2  1994/03/14  19:43:21  damon
NONE	CR 245. Added more CRs
NONE
NONERevision 1.1.8.2  1994/03/14  19:43:04  damon
NONE	CR 245. Added more CRs
NONE
# Revision 1.7  94/01/18  15:49:09  ot
# changed fields: Status   new/changed/deleted note(s) [damon 1/18/94 public]
# 
# Revision 1.6  93/12/15  16:57:44  nata
# added the Created HISTORY line
# 
# Revision 1.5  93/11/24  11:59:38  ot
# changed fields: Status  Fixed In Baseline  
# 
# Revision 1.4  93/11/24  11:11:36  ot
# changed fields: Inter-dependent CRs   new/changed/deleted note(s) [alan 11/24/93 public] [damon 11/24/93 public] [alan 11/24/93 public]
# 
# Revision 1.3  93/11/24  10:36:38  ot
# changed fields: Interest List CC  
# 
# Revision 1.2  93/11/24  10:26:20  ot
# changed fields: Fix By Baseline  Responsible Engr.  Resp. Engr's Company  
# 
# Revision 1.1  93/11/24  10:22:07  ot
# new CR
# 
> # Revision 1.1.1.2  1993/11/24  14:48:35  damon
> #       test
> #
> # $EndLog$
> 
> They prefer the copyright marker and log to be right smack dab together.

[damon 11/24/93 public]
Look what I found in history.c:

 *      CR 716. Complain if bad leader between COPYRIGHT and HISTORY

This was to fix a core dump. Arg.

[damon 1/18/94 public]
Passed 'bci history_separated' test.


CR Number                     : 860
Short Description             : bootstrap build broken on at386_sinix
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : at386
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : Norbert.Marrek@mch.sni.de
Reported Date                 : 11/23/93
Found in Baseline             : 2.3
Found Date                    : 11/23/93
Severity                      : A
Priority                      : 0
Status                        : fix
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : src/ode/bin/make/bootstrap.sh
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 11/23/93 public]
via setup.sh, the bootstrap version of make complains:

make. don't know how to make libode.a

[damon 11/24/93 public]
The whole problem was
that the wrong compiler is used on SINIX, when the setup and
bootstrap shell scripts are executed. I did not notice,
that PATH is changed in setup.sh, so the /usr/ucb/cc was used.

        You have to add the following lines in the 2 files for
        at386_sinix:
====== ./Makeconf ======
455d454
< ANSI_CC=/usr/ccs/bin/cc
====== ./ode/bin/make/bootstrap.sh ======
143d142
<                       CC=/usr/ccs/bin/cc;


With these changes I could execute the setup.sh , and the created make
could be used the create libode.a etc.

[marty 11/24/93 public]
Fixed!  If the build is at386_sinix and /usr/ccs/bin/cc exists, then
that compiler is used.


CR Number                     : 857
Short Description             : update test suite
Defect or Enhancement?        : enh
CR in Code, Doc, or Test?     : test
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : ot (OpenTrack Developers)
Reported Date                 : 11/22/93
Found in Baseline             : 2.3
Found Date                    : 11/22/93
Severity                      : B
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole), marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 11/22/93 public]

[scholz 11/23/93 public]
Actually, the test suite needs to be more than updated.  We need to
extend it considerably to try to cover as much of the typical user
actions as possbible.  We also want it to exercise invalid procedures,
if possible.  Finally, it should be completely turn-key - type one
command, it goes off and runs for a few hours and then dumps the results
or mails them out.  We may be able to borrow a testing scaffold from the
OT group, their test suite is almost completely automated.

[damon 1/27/94 public]
Since we now base the 'closed' status of a CR ( except for this one! ) on
whether or not it has a test case that passes, we can close this CR.
We now have a fully automatic test suite which covers all but 19 of the CRs
for 2.3.4. 8 of these CRs are CRs that are currenlty impossible to handle
with the test suite and will need to be tested by hand. We can add a README
or checklist for these CRs to the test suite build.

In any case, as we continue to update the test suite we will close the
corresponding CRs and no longer need to have a specific CR that covers
all of them, namely this CR.


CR Number                     : 856
Short Description             : man page for odexm
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : doc
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 11/22/93
Found in Baseline             : 2.3
Found Date                    : 11/22/93
Severity                      : C
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : ode/man/man5/odexm.5, ode/man/man5/Makefile
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 11/22/93 public]

[marty 12/16/93 public]
The man page has been created.  It contains general information that I think
is necessary for anyone to set up odexm on their system.  It does not
 go into any detail on "how odexm does  what it does".

[damon 1/28/94 public]
Reviewed. Looks good.


CR Number                     : 852
Short Description             : bmerge -common segvs
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : gm
Reported Date                 : 11/22/93
Found in Baseline             : 2.3
Found Date                    : 11/22/93
Severity                      : A
Priority                      : 0
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 11/22/93 public]
bmerge skips the call to sci_ancestor_list() which looks up the ancestry
information. This is to skip the determination of an ancestor. Unforunately,
this also skips the ancestry lookup. This should be split into two calls. One
to get the raw ancestry information, and one to determine the ancestor to use.

[damon 11/22/93 public]
Separated out the ancestry lookup into sci_ancestry_list().

[damon 1/18/94 public]
Passed 'bmerge common' test.


CR Number                     : 849
Short Description             : "mksb -back /project/osc/build/osc1.3 foo" core dumps
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : mksb
Reported by                   : meissner (Michael Meissner)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 11/22/93
Found in Baseline             : 2.3.3
Found Date                    : 11/22/93
Severity                      : C
Priority                      : 3
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : src/ode/bin/mksb/mksb.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[meissner 11/22/93 public]
If you use the -back switch, mksb core dumps (at least when the backing tree is
/project/osc/build/osc1.3).  Typing in the backing tree when it prompts you
works fine.

[marty 11/22/93 public]
mksb has been fixed.

[damon 12/29/93 public]
Passed 'mksb simple' test.


CR Number                     : 848
Short Description             : bcreate does not special case BIN
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : bcreate
Reported by                   : meissner (Michael Meissner)
Reported by Company           : osf
Interest List CC              : kirschen (David Kirschen)
Reported Date                 : 11/22/93
Found in Baseline             : 2.3
Found Date                    : 11/22/93
Severity                      : A
Priority                      : 1
Status                        : dup
Duplicate Of                  : 599
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : src/ode/lib/libode/sci.c,src/ode/bin/bcreate/bcreate.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[meissner 11/22/93 public]
Bcreate does not recognize the special copyright leader of BIN and accept it
without complaint with the -c option.  The comment leaders field is useless in
this case, since any type of file can be selected to have a BIN leader, and
other files with the same suffix would have the default leader.  This is
important, and stops me dead in the water (I bcreate thousands of files with
BIN leaders every month, and answering the question of keeping the leader would
probably take days of time).

[marty 11/22/93 public]
bcreate now recignized the "BIN" and "NONE" comment leaders.  Also,
if you supply the -auto switch, then bcreate won't verify
your comment leaders either.

[damon 1/27/94 public]
I'm not sure I understand the difference between this CR and CR 599. Since
the test for CR 599 uses a 'bcreate -c BIN' and a 'bcreate -c NONE' when
they are not considered standard comment leaders and it works fine when you
use -auto I think this is moot. So, I am marking this as a dup. If I have
missed something please let me know.

The upshot is that you can do a bcreate -auto -c NONE or bcreate -auto -c BIN
on a file which does not have a recognized comment leader and bcreate will not
complain.


CR Number                     : 847
Short Description             : Speedup mklinks for Motif Group
Defect or Enhancement?        : enh
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : marty (Marty Lynch)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 11/20/93
Found in Baseline             : 2.3
Found Date                    : 11/20/93
Severity                      : C
Priority                      : 4
Status                        : dup
Duplicate Of                  : 703
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 
Affected File(s)              : 
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[marty 11/20/93 public]
Currently the motif group is not using the ODE2.3 version of 'mklinks'
because the added functionality put into mklinks to handle
long backing chains happens to have a performance impact on Motif users.
This is mostly due to Motif's setup of backing chains.

I'll look into speeding it up for them.

[marty 11/20/93 public]
Hmmm,  I can give the motif project a little performance improvement.
I can add an option (that probably would only be good for the motif project
) that could speed up a mklinks of all files in a build from a total time of 
5 minutes 48 seconds to 3 minutes 52 seconds.  These measurements
were taken from a sandbox backed by motif2.0b.


CR Number                     : 845
Short Description             : document exclusive file locking
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : doc
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : rat
Reported Date                 : 11/19/93
Found in Baseline             : 2.3
Found Date                    : 11/19/93
Severity                      : B
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 11/19/93 public]
Exclusive file locking is now documented in the sag. See lock_dirs.

[damon 1/28/94 public]
Reviewed.


CR Number                     : 844
Short Description             : mismatched comparison of ancestry info
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 11/19/93
Found in Baseline             : 2.3
Found Date                    : 11/19/93
Severity                      : B
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.3,2.3.4
Fixed In Baseline             : 2.3.3,2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 11/19/93 public]
The following goof was in a couple of ancestry comparisons:

r = "1.5.1.2";
b = get_branch ( r );
/* b == "1.5.1"
len = strlen ( b );
strncmp ( b, "1.5.11.2 ) == 0

Instead, the branch for both should be determined and the correct comparison
will be "1.5.1" vs. "1.5.11"

[damon 1/21/94 public]
Actually, the above has typos and a missing line. It should be:


r = "1.5.1.2";
b = get_branch ( r );
/* b == "1.5.1" */
len = strlen ( b );
/* len == 5 */
strncmp ( b, "1.5.11.2", len ) == 0

This compares "1.5.1" against "1.5.1".

Instead, the branch for both should be determined and the correct comparison
will be "1.5.1" vs. "1.5.11"

Passed 'bstat good_match' test.


CR Number                     : 843
Short Description             : Include Buildconf.local
Defect or Enhancement?        : enh
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : meissner (Michael Meissner)
Reported by Company           : osf
Interest List CC              : kirschen (David Kirschen), alan (Alan Hamilton), mario (Mario Moreira)
Reported Date                 : 11/19/93
Found in Baseline             : 2.3.3
Found Date                    : 11/19/93
Severity                      : B
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[meissner 11/19/93 public]
Please add an additional file 'Buildconf.local' that is included just like
Buildconf and Buildconf.exp are.  This is needed to prevent problems in long
lived sandboxes where the user needs to modify environment variables (such as
default options, compiler used etc.).  Buildconf and Buildconf.exp cannot be
used, since the current builds use these files, and if a variable is ever
changed or added, it is not propigated to the local sandbox (since the odds of
the user remembering to bmerge every time she builds is dim).  The idea is that
the project NEVER, ever puts anything into Buildconf.local.  Also, in order for
the -all to work in bsubmit, this file should obviously not be checked out.

[damon 12/27/93 public]
Just a reminder that this is here.

[damon 1/20/94 public]
If 'Buildconf.local' exists in the project directory of the rc_files directory
of a sandbox, it will be parsed after all other Buildconf* files.

It is strongly recommended that this feature only be used in special cases such
as those mentioned by Mike above. This is because the Buildconf.local file is
not part of the source tree, is not checked in, and thus outside of regular
development. This makes the duplication of an environment at a future date
more difficult. We should really come up with a better way to do this.

[damon 1/27/94 public]
Passed 'workon buildconf_local' test.


CR Number                     : 841
Short Description             : map file name does not print on error
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 11/19/93
Found in Baseline             : 2.3
Found Date                    : 11/19/93
Severity                      : B
Priority                      : 1
Status                        : fix
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 11/19/93 public]
If there is no entry in the map file pointed to by odexm.conf, you get:

odexm: No match for rcs/ode/test5 in map file (null).

This is less than helpful.


CR Number                     : 840
Short Description             : ODE should not use temporary files in user's src directory in sandbox
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : ezf (Ed Frankenberry), melman (Howard Melman), ratdce, zeliff (Rich Zeliff)
Reported Date                 : 11/18/93
Found in Baseline             : 2.3
Found Date                    : 11/18/93
Severity                      : B
Priority                      : 1
Status                        : fix
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : lib/libode/sci.c,sbdata.c,misc.c,history.c
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 11/18/93 public]
bci creates *.tmp files which may override files that the user has called
foo.tmp.

sadmin creates temp files in ./src

All temp files should be in the tmp directory of the sandbox to avoid
clobbering user's files and allow for easy removal later on.

[marty 12/10/93 public]
The tools no longer create "*.tmp" files in the "src" tree of a sandbox.
All such files are created in the "tmp" directory of the sandbox.

[damon 1/20/94 public]
Files should not be moved across partitions. Changed rename() to copy_file()
in misc.c for sort.tmp.

[damon 1/21/94 public]
copy_file() above is actually cp_file().

Arg. Using /tmp isn't good enough because different users on the same
machine will get name conflicts. Routines like insert_line_in_sorted_file()
should probably use open_temp(<file>) instead of /tmp/<file>.

[damon 1/21/94 public]
What would be wrong with using files in a $HOME/sb/tmp directory
(a temporary directory at the top-level of the user's sandbox)?
        Ed

Some of the routines which use temp files are also on the server where there
is no corresponding directory. However, it may be possible to determine where
we are and act accordingly. I.e., when on the client use $HOME/sb/tmp, when
on the server, use open_temp().

[alan 1/21/94 public]
What's wrong with using open_temp() for all of them?  It avoids all
the problems, including cases we may not have thought about, right?

[damon 1/21/94 public]
Nothing is wrong with using it in all cases. That is actually simpler to do,
and safer as you point out.

[damon 1/31/94 public]
insert_line_in_sorted_file () now uses opentemp().


CR Number                     : 839
Short Description             : edits during bci go into rcs file but not into sandbox file
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 11/18/93
Found in Baseline             : 2.3
Found Date                    : 11/18/93
Severity                      : D
Priority                      : 1
Status                        : fix
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : src/ode/lib/libode/sci.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 11/18/93 public]
If you are in bci and select [edit] and change the file, the changes go into
the checked in file but the file in your sandbox does not get the changes.

[marty 11/23/93 public]
I changed the routine real_check_in() to detect that if the temporary
file was edited before rcs check-in, then the temporary file is copied 
back into the users sandbox.


CR Number                     : 838
Short Description             : RAT admin with/for external providers less secure
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : robert (Rob Dicamillo)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 11/18/93
Found in Baseline             : 2.3
Found Date                    : 11/18/93
Severity                      : B
Priority                      : 1
Status                        : dup
Duplicate Of                  : 813
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 
Affected File(s)              : 
Responsible Engr.             : 
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[robert 11/18/93 public]

Ode 2.3 introduces more admin tasks on the RCS server side (presumably to
accommodate less client server interaction). However, this increased requirement
for RAT admin outweighs the convenience of less client-server interaction;
the priority of revamping client-server has been over-emphasized.

RATS from different cites/time zones must all have access as root to a common sets
dir under every rcs base on common rcs servers. Cites may be confused and inadvertently
break dynamic builds for other cites when editing or deleting set file names that differ
by only a few characters. Time zone differences make it impractical for
"RATS in the U.S.A." (forthcoming hit single from "Big Cheese" Records), and Grenoble
Rats to perform admin work for each other.

Cites should becomre more decoupled and not more closely coupled for the purposes
of admin work.


CR Number                     : 837
Short Description             : bsubmit creates extra log files
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : robert (Rob Dicamillo)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 11/18/93
Found in Baseline             : 2.3
Found Date                    : 11/18/93
Severity                      : D
Priority                      : 1
Status                        : fix
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[robert 11/18/93 public]

On a clean abort from bsubmit during bmerge, a log file is
generated.

[damon 11/18/93 public]
This is not a big deal, but it should be fixed.


CR Number                     : 836
Short Description             : snapshot file now overloaded
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : robert (Rob Dicamillo)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 11/18/93
Found in Baseline             : 2.3
Found Date                    : 11/18/93
Severity                      : C
Priority                      : 3
Status                        : cancel
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 
Affected File(s)              : 
Responsible Engr.             : 
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[robert 11/18/93 public]

The SNAPSHOT file is still the key
mechanism for external providers to determine if they've sync'd up
to OSF. Hence, it is confusing for more then one revision to be stored
in this file, especially when one revision may be wrong (the SNAPSHOT file
is still not guaranteed to be updated correctly). Rather then expand the function
of the "incorrect" SNAPSHOT file, it would be preferable to invent a new file for
ancestry (maybe ANCESTOR?), and fix the existing SNAPSHOT file (or provide some
equivalent mechanism for external providers to sync up).

But the current info in the SNAPSHOT file only makes ODE even more
confusing to external contributors.

[marty 11/18/93 public]
Rob, I've got to stop you on this one.  It is trivial for you to tell
your providers how to interpret the new SNAPSHOT file format.  The format
really isn't all that different to begin with.  You just have extract 2 fields
instead of 3 fields from this file.  You can do this with the `cut -f1,2 SNAPSHOT`
command before piping it to whatever tool is currently looking at the SNAPSHOT file.
I'm canceling this because, with a little work, you and your providers can easily
adapt to this change.
 
how providers a


CR Number                     : 835
Short Description             : aliasing of commands in .sandboxrc does not work
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : robert (Rob Dicamillo)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 11/18/93
Found in Baseline             : 2.3
Found Date                    : 11/18/93
Severity                      : C
Priority                      : 3
Status                        : cancel
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 
Affected File(s)              : 
Responsible Engr.             : 
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[robert 11/18/93 public]

The advertised feature of customizing commands with entries in the
.sandboxrc file does not work. For example, as bcreate is too
quiet now, it would be nice to alias "bcreate" to "bcreate -verbose",
but entering "bcreate -verbose" in .sandboxrc does not change the default
output of bcreate.

[damon 11/18/93 public]
This feature works great. Try putting bcreate -debug in your .sandboxrc.
The only difference between bcreate and bcreate -verbose is that bcreate will
print:

>  Reading rc file : /usr/users/damon/.sandboxrc

If you do bcreate -verbose without -verbose in the .sandboxrc. This is
because this message is printed prior to reading the .sandboxrc file which
contains the 'bcreate -verbose' entry. This is a chicken and egg problem
which is not really worth solving. If it is felt that bcreate should
say more with -verbose, then a separate CR should be opened stating this.


CR Number                     : 834
Short Description             : 2.3 make and makefiles inadequately tested
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : robert (Rob Dicamillo)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 11/18/93
Found in Baseline             : 2.3
Found Date                    : 11/18/93
Severity                      : A
Priority                      : 3
Status                        : cancel
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 
Affected File(s)              : 
Responsible Engr.             : 
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[robert 11/18/93 public]

Re-issuing the build command (after a build from scratch) and
piecemeal rebuilding was not tested. This was immediately noticed
for the ./osf1_server.

[damon 11/18/93 public]
This is not an ODE issue. This sort of exhaustive testing is impractical.
The work that needs to be done to fix this is either done or underway and is
entirely a project makefiles issue.


CR Number                     : 833
Short Description             : set creation/info no longer local to build server
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 832
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : robert (Rob Dicamillo)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 11/18/93
Found in Baseline             : 2.3
Found Date                    : 11/18/93
Severity                      : A
Priority                      : 4
Status                        : dup
Duplicate Of                  : 813
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 
Affected File(s)              : 
Responsible Engr.             : 
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[robert 11/18/93 public]

It is no longer possible to create/modify a label for a (new) build
without editing files on the RCS server. This is a major
admin pain. Maintaining or creating the default set names for dynamic builds
should only require changes local to the build server. This is also
a source of potential security problems - all RATS from
external cites have to be able to edit the sets subdir
under common/shared rcs bases.

Although config information is more logically separated into
build and source control config files, this "convenience" is
outweighed by the penalty of having to maintain multiple config files
on the RCS server.

It would appear that optimizing client - server operations
(presumably for the speed of bsubmit) has taken a toll
on the organization and scope of config information (also
see bug #832).


CR Number                     : 827
Short Description             : bci -xlog deleted, no equivalent function
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 817
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : jeffc (Jeff Carter)
Reported by Company           : osf
Interest List CC              : watkins (Peter Watkins), osf1-team
Reported Date                 : 11/18/93
Found in Baseline             : 2.3.3
Found Date                    : 11/18/93
Severity                      : B
Priority                      : 2
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : src/ode/lib/libode/sci.c,ode/bin/bci/bci.c
Responsible Engr.             : marty (Marty Lynch), damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[jeffc 11/18/93 public]
The "bci" command in ODE 2.3 and 2.3.3 no longer contains the "-xlog"
option. This was used in previous versions of ODE to build the default
check-in log message be extracting (and removing) the log message from
another branch.

The feature was extremely useful when performing either of 2 very
common operations: (1) the final checkin after a series of changes, to edit
down the log entry to a meaningful entry in preparation for submission,
and (2) when merging code from one branch (or sandbox) to another, so that
the local (merged) checkin has the revision history from the other branch.

For example, the old procedure to merge from "fred's" sandbox was:

bmerge -auto -rfred_osc file.c
bci -xlog fred_osc -auto file.c

This can be performed with no human interaction. Without -xlog, I must
manually edit each file between the merge & check-in.

Both of the above functions are (were) performed frequently, and removing
the functionality from the tools makes the operations less efficient, and
therefore, the engineers less productive.

[damon 11/18/93 public]
I understand (2) fairly well, but am a bit hazy on (1). Could you elaborate?

[marty 12/7/93 public]
Jeff, the changes for bci have been tested and submitted to ode2.3.4.
I left a copy of it in soba:/tmp/bci.

[damon 1/18/94 public]
This should default to the user's branch. Need to add -r to refer
to a specific revision.

[damon 2/4/94 public]
Changed -xlog to -x. -x takes no options. User's branch is taken by default.
If a different branch is desired, use -r.

Passed 'bci xlog_option' test.


CR Number                     : 824
Short Description             : Unexpected EOF in bci
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : meissner (Michael Meissner)
Reported by Company           : osf
Interest List CC              : kirschen (David Kirschen), ratosc
Reported Date                 : 11/17/93
Found in Baseline             : 2.3.2
Found Date                    : 11/17/93
Severity                      : B
Priority                      : 1
Status                        : cancel
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 
Affected File(s)              : 
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[meissner 11/17/93 public]
The message for improper markers gets emitted as: 'Unexpected end of file'.
Here is the bci output with -debug turned on:

>  Reading rc file : /usr/users/meissner/.sandboxrc
>> DEBUG INFO in ui_init:
>> Tokens are:
>> -quiet
>> -auto
>> DEBUG INFO in ui_init:
>> Contents of interface table:
>> 1 : -nolog: maxe=1; dup=0; mina=0; maxa=0; a=.
>> 3 : -sb: maxe=1; dup=0; mina=1; maxa=1; a=!-*.
>> 8 : -auto: maxe=1; dup=0; mina=0; maxa=0; a=.
>>     e=-auto; numa=0; nume=1.
>>     -changed: maxe=1; dup=0; mina=0; maxa=0; a=.
>> 14: -all: maxe=1; dup=0; mina=0; maxa=0; a=.
>> 20: -sb_rc: maxe=1; dup=0; mina=1; maxa=1; a=!-*.
>>     -m: maxe=1; dup=0; mina=1; maxa=1; a=!-*.
>> 25: !-*: maxe=-1; dup=0; mina=0; maxa=0; a=.
>>     e=AT386/ptrace.s; numa=0; nume=1.
>> 26: -rc: maxe=1; dup=0; mina=1; maxa=1; a=!-*.
>>     -fast: maxe=1; dup=0; mina=0; maxa=0; a=.
>> 37: -set: maxe=1; dup=0; mina=1; maxa=1; a=!-*.
>> 39: -saved: maxe=1; dup=0; mina=0; maxa=0; a=.
>> 42: -info: maxe=1; dup=0; mina=0; maxa=0; a=.
>> 52: -defunct: maxe=1; dup=0; mina=0; maxa=0; a=.
>> vl=7; ap=8; ip=42.
>> DEBUG INFO in bci:
>> Entering sci_init
>> DEBUG INFO in current_sb:
>> Found sb name in environment.  Name is: osf1.
>> DEBUG INFO in current_sb:
>> sb name is in rc file.  Name is: osf1.
>> DEBUG INFO in current_sb:
>> Found base dir in rcfile. Dir is: /usr/sandbox/meissner.
>> DEBUG INFO in current_sb:
>> Using default sandbox rc file: /usr/sandbox/meissner/osf1/rc_files/local.
>> DEBUG INFO in current_sb:
>> sb name is in rc file.  Name is: osf1.
>> DEBUG INFO in current_sb:
>> Found base dir in rcfile. Dir is: /usr/sandbox/meissner.
>> DEBUG INFO in current_sb:
>> Using default sandbox rc file: /usr/sandbox/meissner/osf1/rc_files/local.
>> DEBUG INFO in current_set:
>> matched set, meissner_osf1, and setdir, ., in sb rcfile.
>> DEBUG INFO in bci:
>> Composing list of legal copyright markers.
>> DEBUG INFO in bci:
>> Using default copyright markers.
>> DEBUG INFO in bci:
>> Looking for copyright markers in string:
>> OSF_COPYRIGHT;OSF_FREE_COPYRIGHT 
>> DEBUG INFO in bci:
>> Entry 1: OSF_COPYRIGHT
>> DEBUG INFO in bci:
>> Entry 2: OSF_FREE_COPYRIGHT
>> DEBUG INFO in bci:
>> Leaving sci_init
>> DEBUG INFO in bci:
>> Entering sci_new_list
>> DEBUG INFO in bci:
>> Leaving sci_new_list
>> DEBUG INFO in bci:
>> Depth: 0. Entering 'sci_add_to_list'.
>> DEBUG INFO in bci:
>> Adding AT386/ptrace.s to a list.
>> DEBUG INFO in bci:
>> Depth: 1. Entering 'sci_add_to_list_as_is'.
>> DEBUG INFO in bci:
>> Adding ./usr/ccs/lib/libc/AT386/ptrace.s to a list.
>> DEBUG INFO in bci:
>> Depth: 1. Leaving 'sci_add_to_list_as_is'.
>> Returning to 'sci_add_to_list'
>> DEBUG INFO in bci:
>> Depth: 0. Leaving 'sci_add_to_list'.
>> DEBUG INFO in bci:
>> entry number: 2, greater than number of entries: 1.
authcover skippy.osf.org rcs/osc/osc1.3 549
>> DEBUG INFO in bci:
>> Remote command:
>> rlog
>> -h
>> ./usr/ccs/lib/libc/AT386/ptrace.s
>> DEBUG INFO in bci:
>> In sci_get_comment_leader, leader is ' * '
>> DEBUG INFO in bci:
>> process exited with 0>> DEBUG INFO in bci:
>> Entering sci_lookup_user_rev_list.
authcover skippy.osf.org rcs/osc/osc1.3 549
>> DEBUG INFO in bci:
>> Depth: 0. Entering 'src_ctl_lookup_revision'.
>> DEBUG INFO in bci:
>> Depth: 1. Entering 'rcsfullstat'.
>> DEBUG INFO in bci:
>> Remote command:
>> rcsstat
>> -q
>> -D
>> -V
>> -rmeissner_osf1
>> ./usr/ccs/lib/libc/AT386/ptrace.s
>> DEBUG INFO in bci:
>> rcsstat returned revision 3.0.6.1
>> DEBUG INFO in bci:
>> Depth: 1. Leaving 'rcsfullstat'.
>> Returning to 'src_ctl_lookup_revision'
>> DEBUG INFO in bci:
>> Depth: 0. Leaving 'src_ctl_lookup_revision'.
>> DEBUG INFO in bci:
>> process exited with 0>> DEBUG INFO in bci:
>> Leaving sci_lookup_user_rev_list.
authcover skippy.osf.org rcs/osc/osc1.3 549
>> DEBUG INFO in bci:
>> Depth: 0. Entering 'check_path'.
>> DEBUG INFO in bci:
>> Depth: 0. Leaving 'check_path'.
>> DEBUG INFO in bci:
>> Entering copy_file
>> DEBUG INFO in bci:
>> src :./usr/ccs/lib/libc/AT386/ptrace.s:
>> DEBUG INFO in bci:
>> dst :/usr/sandbox/meissner/osf1/tmp/ptrace.s:
>> DEBUG INFO in bci:
>> Leaving copy_file
>> DEBUG INFO in bci:
>> process exited with 0>> DEBUG INFO in bci:
>> Depth: 0. Entering 'hst_lookup_logmsg'.
>> DEBUG INFO in bci:
>> Depth: 1. Entering 'src_ctl_extract_history'.
>  Scanning for HISTORY
>> DEBUG INFO in bci:
>> Depth: 2. Entering 'process_log_messages'.
>> DEBUG INFO in bci:
>> Depth: 2. Leaving 'process_log_messages'.
>> Returning to 'src_ctl_extract_history'
>> DEBUG INFO in bci:
>> Depth: 1. Leaving 'src_ctl_extract_history'.
>> Returning to 'hst_lookup_logmsg'
>> DEBUG INFO in bci:
>> Depth: 0. Leaving 'hst_lookup_logmsg'.
>> DEBUG INFO in bci:
>> Depth: 0. Entering 'okmesg'.
>> DEBUG INFO in bci:
>> Depth: 0. Leaving 'okmesg'.
authcover skippy.osf.org rcs/osc/osc1.3 549
>> DEBUG INFO in bci:
>> Depth: 0. Entering 'okmesg'.
>> DEBUG INFO in bci:
>> Depth: 0. Leaving 'okmesg'.
>> DEBUG INFO in bci:
>> Depth: 0. Entering 'search for'.
>> DEBUG INFO in bci:
>> Depth: 0. Leaving 'search for'.
>> DEBUG INFO in bci:
>> Depth: 0. Entering 'search for'.
>> DEBUG INFO in bci:
>> Depth: 0. Leaving 'search for'.
>> DEBUG INFO in bci:
>> checking: @OSF_COPYRIGHT@
>> DEBUG INFO in bci:
>> checking: @OSF_FREE_COPYRIGHT@
>> DEBUG INFO in bci:
>> Couldn't find matching copyright marker for:  * COPYRIGHT NOTICE
>> DEBUG INFO in bci:
>> Depth: 0. Entering 'search for'.
>> DEBUG INFO in bci:
>> Depth: 0. Leaving 'search for'.
>> DEBUG INFO in bci:
>> Depth: 0. Entering 'search for'.
>> DEBUG INFO in bci:
>> Depth: 0. Leaving 'search for'.
>> DEBUG INFO in bci:
>> Depth: 0. Entering 'search for'.
>> DEBUG INFO in bci:
>> Depth: 0. Leaving 'search for'.
>> DEBUG INFO in bci:
>> Depth: 0. Entering 'search for'.
>> DEBUG INFO in bci:
>> Depth: 0. Leaving 'search for'.
>> DEBUG INFO in bci:
>> Depth: 0. Entering 'search for'.
>> DEBUG INFO in bci:
>> Depth: 0. Leaving 'search for'.
>> DEBUG INFO in bci:
>> Depth: 0. Entering 'search for'.
>> DEBUG INFO in bci:
>> Depth: 0. Leaving 'search for'.
>> DEBUG INFO in bci:
>> Depth: 0. Entering 'search for'.
>> DEBUG INFO in bci:
>> reached EOF reading input file
Unexpected end of file
>> DEBUG INFO in bci:
>> Depth: 0. Leaving 'search for'.
>> WARNING in bci:
>> Improper markers or history section in file ./usr/ccs/lib/libc/AT386/ptrace.s
>> DEBUG INFO in bci:
>> process exited with 0

[marty 11/19/93 public]
Unable to reproduce this problem.  Mike, this may be due to OSC being 
upgraded to ODE 2.3 while FSF was still at ODE2.1.  I tried reproducing this
problem in your environment today and things seem to work just fine.
I'm canceling this CR.  If this problem becomes more persistent then
I'll look into it again.


CR Number                     : 819
Short Description             : bci xtract fails to extract log
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : grant (Grant Sullivan)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 11/16/93
Found in Baseline             : 2.3.3
Found Date                    : 11/16/93
Severity                      : C
Priority                      : 2
Status                        : cancel
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 
Affected File(s)              : 
Responsible Engr.             : 
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : handson
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[grant 11/16/93 public]
Today I did a bco of src/usr/man/man.c, in a sandbox backed against osc1.3,
made some changes, updated the log info, then tried to do a bci.  The
"bci" did not appear to do an automatic "xtract", so I specified "xtract" when
"bci" asked for a log, and it still failed to generate a log.

I'm sure the log is properly formatted.  Here is the source log info
from the file:

vishnu:/usr/sandbox/grant_sand/src/usr/bin/man/man.c
========================================================================
/*
 * COPYRIGHT NOTICE
 * Copyright (c) 1990, 1991, 1992, 1993 Open Software Foundation, Inc.
 * ALL RIGHTS RESERVED (OSF/1).  See /usr/include/COPYRIGHT.OSF1 .
 */
/*
 * HISTORY
 * 	CR 8743.  Changed all error message output to output to stderr, instead
 * 	  of to stdout.
 * $Log: change_requests,v $
NONERevision 1.1.7.2  1994/03/14  19:43:21  damon
NONE	CR 245. Added more CRs
NONE
NONERevision 1.1.8.2  1994/03/14  19:43:04  damon
NONE	CR 245. Added more CRs
NONE
# Revision 1.4  93/12/15  17:02:26  nata
# added the Created HISTORY line
# 
# Revision 1.3  93/11/17  13:46:35  ot
# changed fields: Status   new/changed/deleted note(s) [grant 11/16/93 public] [damon 11/17/93 public] [grant 11/16/93 public]
# 
# Revision 1.2  93/11/16  17:51:04  ot
# changed fields:  new/changed/deleted note(s) [grant 11/16/93 public]
# 
# Revision 1.1  93/11/16  17:05:22  ot
# new CR
# 
 * Revision 3.0.2.4  1993/09/16  01:14:51  dsb
 * 	CR 9705.  Change catopen() call to use LC_MESSAGES.
 * 	[1993/09/15  21:58:16  dsb]
 * 
 * Revision 3.0.2.3  1993/09/15  02:34:00  alan
 * 	Replaced copyright marker with copyright text
 * 	[1993/09/14  22:41:40  alan]
 * 
 * 	replaced copyright marker with copyright text
 * 	[1993/09/09  00:11:15  alan]
 * 
 * Revision 3.0.2.2  1993/02/10  22:04:34  dsb
 * 	Bug 8672. Modified stat() algorithm to compare the times of the
 * 	"real" man/cat pages when the specified page is really just
 * 	a .so entry.
 * 	[1993/02/10  22:04:03  dsb]
 * 
 * Revision 3.0  1993/01/01  02:25:02  ede
 * 	Initial revision for OSF/1 R1.3
 * 
 * Revision 1.12.5.3  1992/10/15  18:58:09  lehotsky
 * 	CR 7977 - wrong message number used
 * 	[1992/10/15  18:46:10  lehotsky]
 * 
 * Revision 1.12.5.2  1992/09/18  15:04:57  tom
 * 	Bug 7445 - Read /dev/tty instead of stdin when prompting for enter.
 * 	Also don't use fgets, just read chars till newline.
 * 	[1992/09/17  20:56:43  tom]
 * 
 * Revision 1.12.3.2  1992/05/26  14:17:14  dwm
 * 	Bug 6415: calloc failure ignored.
 * 	[1992/04/25  18:21:42  dwm]
 * 
 * Revision 1.12.1.9  1992/03/23  22:46:06  tom
 * 	Bug 5866 - man prompt user to hit enter when it shouldn't.
 * 	[1992/03/23  22:45:34  tom]
 * 
 * Revision 1.12.1.8  1992/03/17  23:00:09  tom
 * 	Bug 5724 - add '-h' to nroff command for terminals, remove -Tlp.
 * 	[1992/03/17  22:59:34  tom]
 * 
 * Revision 1.12.1.7  1992/03/13  23:08:34  mori_m
 * 	man complains when only '/' is specified (#4993)
 * 	[1992/03/13  23:08:05  mori_m]
 * 
 * Revision 1.12.1.6  1992/03/02  19:56:17  tom
 * 	Fix .so bug in manual().
 * 	[1992/03/02  18:29:30  tom]
 * 
 * Revision 1.12.1.5  1992/02/18  20:27:09  damon
 * 	Removed I B M  C O N F I D E N T I A L messages
 * 	[1992/02/14  15:50:26  damon]
 * 
 * Revision 1.12.1.4  1991/11/06  17:15:38  tom
 * 	Attempt a cleanup:
 * 	Fix leaving a temp file around.
 * 	Add the -c and -w switches. (c is the same as '-').
 * 	[91/11/06  17:10:08  tom]
 * 
 * Revision 1.12.1.3  91/10/11  14:45:57  tom
 * 	Bug 2669: remove trap from shell command.
 * 	[91/10/11  14:45:13  tom]
 * 
 * Revision 1.12  91/10/09  15:11:17  devrcs
 * 	Bug 2730,remove tab M_MSG_18.
 * 	[91/10/09  11:23:53  sgrainge]
 * 
 * Revision 1.11  91/08/30  17:42:05  devrcs
 * 	Code parsing 'section' had incorrect test for ascii...
 * 	[91/08/26  14:05:02  lehotsky]
 * 
 * Revision 1.10  91/08/20  15:32:28  devrcs
 * 	Changed definition of CAT_ and CAT_S to be /usr/bin/cat.  Changed
 * 	function displayoutput to use /usr/bin/rm instead of /bin/rm.
 * 	Changed function manual to use /usr/bin/mv instead of /bin/mv.
 * 	[91/08/15  14:08:47  whalen]
 * 
 * 	Add/cleanup rcsid's.
 * 	[91/08/01  14:44:58  tom]
 * 
 * 	NLS cleanup.  Removed bogus inline code for pattern matching in apropos
 * 	and whatis and replaced with POSIX regular expression code.
 * 	[91/07/19  09:36:22  lehotsky]
 * 
 * Revision 1.9  91/05/14  12:51:22  devrcs
 * 	Fix usage message to include -t flag
 * 	[91/04/19  10:03:31  lehotsky]
 * 
 * Revision 1.8  91/03/04  17:35:33  devrcs
 * 	Fix sigset_t initializations and mark int dependencies.
 * 	[90/12/13  10:32:05  dwm]
 * 
 * Revision 1.7  91/01/07  13:18:01  devrcs
 * 	Corrected misleading error message.
 * 	[90/11/09  14:30:17  tom]
 * 
 * Revision 1.6  90/10/31  14:52:09  devrcs
 * 	Added -Tlp switch to nroff command.
 * 	Changed manpath to /usr/share/man.
 * 	Corrected path to cat.
 * 	[90/10/12  09:46:31  tom]
 * 
 * Revision 1.5  90/10/07  16:43:31  devrcs
 * 	Added EndLog Marker.
 * 	[90/09/28  14:50:16  gm]
 * 
 * Revision 1.4  90/09/23  16:24:14  devrcs
 * 	Cleanup source to remove unnec ifdefs
 * 	[90/09/12  16:42:39  lehotsky]
 * 
 * 	Added /usr/local/man to default manpath.
 * 	[90/09/12  14:09:31  glenn]
 * 
 * 	Fixed bug #840:  The usage string and many args failure.
 * 	Fixed bug #841:  Core dumping errors
 * 	[90/09/06  04:19:35  staffan]
 * 
 * 	Fixed the bug causing "man -M x" to core dump
 * 	[90/09/03  09:50:46  staffan]
 * 
 * Revision 1.3  90/08/24  13:14:50  devrcs
 * 	Expanded NLrdefs.h in place.
 * 	[90/08/18  17:22:03  gm]
 * 
 * 	Correct SIGSEGV in runpath caused by bad AIX expression
 * 	(missing parens) caused improper evaluation order and
 * 	resulting dereference of a pointer.
 * 	[90/08/10  15:29:58  lehotsky]
 * 
 * Revision 1.2  90/06/29  14:00:55  devrcs
 * 	Remove warnings about incompatible pointer types
 * 	[90/06/20  10:53:29  lehotsky]
 * 
 * 	Populate from AIX sources
 * 	[90/06/19  21:17:02  lehotsky]
 * 
 * $EndLog$
 */
#if !defined(lint) && !defined(_NOIDENT)
static char rcsid[] = "@(#)$RCSfile: change_requests,v $ $Revision: 1.1.7.2 $ (OSF) $Date: 1994/03/14 19:43:21 $";
#endif
/*
 * COMPONENT_NAME: (CMDMAN) commands that allow users to read online
 * documentation
 *
 * FUNCTIONS: runpath, manual, pathstat, nroff, troff, local_remove,
 *	      blklen, apropos, match, amatch, lmatch_sjis, lmatch, whatis,
 *	      wmatch, tail, usage, usage2
 *
 *
 * (C) COPYRIGHT International Business Machines Corp. 1985, 1989 
 * All Rights Reserved
 *
 * US Government Users Restricted Rights - Use, duplication or
 * disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
 *
 * Copyright (c) 1980 Regents of the University of California.
 * All rights reserved.  The Berkeley software License Agreement
 * specifies the terms and conditions for redistribution.
 * 
 * 1.28  com/cmd/man/man.c, cmdman, bos320, 9125320c 6/12/91 11:52:30
 */

============================================================================

[grant 11/16/93 public]
I just found out from Jeff C. that bci's "log" already does silently
what "xtract" used to do explicitly.

[damon 11/17/93 public]
Unless I have misunderstood something, xtract works the same now as before.
xtract is not used normally. It is only used if bci complains about the
log/history section and requires you to fix it. After that point, xtract will
re-extract the log information for the default contents of the log.

bci has always and continues to do an automatic xtract prior to the [check-in]
prompt.


CR Number                     : 818
Short Description             : workon requires -setdir instead of
optionally
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : grant (Grant Sullivan)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 11/16/93
Found in Baseline             : 2.3.3
Found Date                    : 11/16/93
Severity                      : C
Priority                      : 3
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : handson
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[grant 11/16/93 public]
The workon(1) manpage indicates that the -setdir option is optional, but
if I do
	workon -set <setname>
for an already-created set, I find I end up at <sandbox>/src, instead of
at <sandbox>/src/<setdir>.

I have to do
	workon -setdir <setdir> -set <setname>
for an already created set, instead of assuming "workon" would cd to the
directory specified in <sandbox>/rc_files/sets.

Is this a bug in "workon" or an documentation error in the workon(1) manpage?

[damon 11/16/93 public]
This is a bug.

[damon 1/4/94 public]
Passed 'workon other_set' test.


CR Number                     : 815
Short Description             : bci ignores auto when given entered at bci's prompt
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 11/16/93
Found in Baseline             : 2.3
Found Date                    : 11/16/93
Severity                      : C
Priority                      : 3
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : src/ode/lib/libode/sci.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 11/16/93 public]

[marty 11/16/93 public]
It works now.

[damon 12/30/93 public]
Modified 'bci no_auto' test to switch to auto on the 8th file.
Passed 'bci no_auto' test.


CR Number                     : 814
Short Description             : supscan & supfilesrv are missing from ode 2.3
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : meissner (Michael Meissner)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 11/16/93
Found in Baseline             : 2.3.2
Found Date                    : 11/16/93
Severity                      : C
Priority                      : 3
Status                        : cancel
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 
Affected File(s)              : 
Responsible Engr.             : 
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[meissner 11/16/93 public]
The programs supscan and supfilesrv are missing from ODE 2.3.2 on the 386
running OSF/1.  It is impossible to maintain private sup collections if these
programs are missing.

[damon 11/16/93 public]
These have moved from /usr/ode/bin to /usr/ode/server. This makes it easier
to set up the server side of ODE. Just copy /usr/oder/server and you have most
of what you need for your ODE server.

I will leave this CR open for comment.

[damon 11/19/93 public]
No comments received. cancelling.


CR Number                     : 812
Short Description             : Remove sindex from man/{man3,cat3}/Makefile
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : marty (Marty Lynch)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 11/15/93
Found in Baseline             : 2.3
Found Date                    : 11/15/93
Severity                      : C
Priority                      : 3
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : src/ode/man/{man,cat}3/Makefile
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[marty 11/15/93 public]
sindex.3 has been defuncted. References to it should be removed from
the Makefiles.

[marty 11/15/93 public]
Fixed.

[damon 1/28/94 public]
Checked.


CR Number                     : 807
Short Description             : bsubmit should do a bit less when interrupted during merging
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : robert (Rob Dicamillo)
Reported Date                 : 11/14/93
Found in Baseline             : 2.3
Found Date                    : 11/14/93
Severity                      : D
Priority                      : 2
Status                        : fix
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 11/14/93 public]
Hmm. Couldn't think of a better short description.
Anyway, bsubmit_s should realize that if it is asked to do a bsubmit -rm
when the saved state is the merge step that it doesn't need to validate or
create a log or anything else other than remove the entries from the hold file.

The stuff it currently prints out can be confusing to users.


CR Number                     : 806
Short Description             : sbinfo should indicate when there is no default sandbox
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : Norbert.Marrek@mch.sni.de
Reported Date                 : 11/12/93
Found in Baseline             : 2.3
Found Date                    : 11/12/93
Severity                      : C
Priority                      : 3
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 11/12/93 public]
Currently it complains that it can't find the proper files but it should
say that there is no default sandbox.

[damon 11/16/93 public]
On SNI platforms this prints out strange messages.

[damon 1/4/93 public]
Passed 'sbinfo no_default_sb' test.


CR Number                     : 804
Short Description             : document sb.conf
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : doc
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 11/12/93
Found in Baseline             : 2.3
Found Date                    : 11/12/93
Severity                      : C
Priority                      : 3
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 11/12/93 public]
Added description of all four variables in sb.conf to sag.

[damon 1/28/94 public]
Reviewed.


CR Number                     : 801
Short Description             : document locking a sandbox
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : rat
Reported Date                 : 11/12/93
Found in Baseline             : 2.3
Found Date                    : 11/12/93
Severity                      : C
Priority                      : 3
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 11/12/93 public]
Need to document lock_sb in the backing build logs directory.

[damon 11/19/93 public]
Also documented fine grained locking of the backing tree.

[damon 1/28/94 public]
Reviewed.


CR Number                     : 800
Short Description             : bootstrap.sh needs some updating
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 11/12/93
Found in Baseline             : 2.3
Found Date                    : 11/12/93
Severity                      : C
Priority                      : 3
Status                        : fix
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 11/12/93 public]
For instance, CC=c89 or CC=gcc should be added for hp700_hpux.


CR Number                     : 794
Short Description             : document new COPYRIGHT NOTICE handling
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : doc
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 11/11/93
Found in Baseline             : 2.3
Found Date                    : 11/11/93
Severity                      : C
Priority                      : 3
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 11/11/93 public]
Both the sag and the User's Guide have been updated for administration and
day-to-day usage details.

[damon 1/28/94 public]
Reviewed.


CR Number                     : 793
Short Description             : supfilesrv doesn't handle EINTR when figuring out byte order
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : peckham@tuxedo.enet.dec.com
Reported by Company           : dec
Interest List CC              : 
Reported Date                 : 11/11/93
Found in Baseline             : 2.3
Found Date                    : 11/11/93
Severity                      : B
Priority                      : 3
Status                        : fix
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 11/11/93 public]
supfilesrv exits ( possibly with a core dump ) when it should instead check
for EINTR and try again. Alternatively, we should indicate that functions
should be restarted when interrupted.

[damon 11/24/93 public]
A check for EINTR has been added to service() for the first read.
Note that the accept call preceding the read already checks for EINTR. If the
problem moves to the next system call, then this problem should be investigated
further.


CR Number                     : 790
Short Description             : bcreate -undo says nothing if it fails
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 11/10/93
Found in Baseline             : 2.3
Found Date                    : 11/10/93
Severity                      : C
Priority                      : 3
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 11/10/93 public]
bcreate -undo should say something if it was not able to undo the file.
bcreate -undo of a file that has been submitted says nothing.

[damon 12/29/93 public]
Added and passed 'bcreate undo_no_user_branch' test.


CR Number                     : 788
Short Description             : configurable odexm.conf location
Defect or Enhancement?        : enh
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 11/10/93
Found in Baseline             : 2.3
Found Date                    : 11/10/93
Severity                      : C
Priority                      : 3
Status                        : fix
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 11/10/93 public]
odexm should have a switch which tells it where to look for odexm.conf so
that this can be set in inetd.conf

[damon 11/22/93 public]
If an argument is given to odexm, it will use that as the odexm.conf file.
Otherwise, it will default to /etc/odexm.conf .


CR Number                     : 785
Short Description             : salloc referred to in man pages
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : mullan_s@apollo.hp.com
Reported by Company           : hp
Interest List CC              : sommerfeld@apollo.hp.com
Reported Date                 : 11/10/93
Found in Baseline             : 2.3
Found Date                    : 11/10/93
Severity                      : C
Priority                      : 3
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3
Affected File(s)              : src/ode/man/man3/Makefile
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 11/10/93 public]

    The variable MANSOURCE includes a file named salloc, but there is
    no corresponding man page in that directory.

    Removed reference to salloc from MANSOURCE.

[marty 11/14/93 public]
Fixed some time ago.

[damon 2/24/94 public]
Reviewed.


CR Number                     : 773
Short Description             : user's set can not be same as backing build set
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 869
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : sommerfeld@apollo.hp.com, alan (Alan Hamilton)
Reported Date                 : 11/2/93
Found in Baseline             : 2.3
Found Date                    : 11/2/93
Severity                      : B
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 11/2/93 public]
I thought that this was a long standing CR ( CR 375 ), but that is the
opposite of this.

[damon 11/2/93 public]
Actually, this is a long standing bug from the point of view that it has
always been there. :-(.

I adjusted the severity/priority because as Bill points out, this can have
very harmful effects.

[damon 11/2/93 public]
bco, bcs, and bsubmit now check to make sure that the user's set and the submit
set do not match. If there is a match, the tools complain and exit.

If ODE source control is being used, mksb should also be modified to check for
a match.

[damon 11/22/93 public]
mksb has been updated, as well as workon.

[damon 11/30/93 public]
This needs to be extended to bci and bmerge.

[damon 1/18/94 public]
Passed 'special bad_user_set' test.


CR Number                     : 772
Short Description             : bcreate -undo fails if no revisions in file
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 11/2/93
Found in Baseline             : 2.3
Found Date                    : 11/2/93
Severity                      : C
Priority                      : 3
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : lib/libode/sci.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 11/2/93 public]
If a newly created file somehow exists but does not contain any revisions,
bcreate -undo will fail.

[marty 1/05/94 public]
bcreate will now remove a file under the following conditions.
o   A single branch (1.1.1.1) exists with your setname labeld to it (i.e. you created it)

or 

o   There are NO revisions or symbolic names to be found in the RCS file.

Here's the commands we're trying to look out for:

bcreate foo.c                        /* If you want to remove it you can type.*/
bcreate -undo foo.c


or

bcreate foo.c				
bcs -o foo.c				/* Opps, that's not what I wanted to do. */
bcreate -undo foo.c			/* Will now remove the file from RCS.  */

[damon 1/21/94 public]
Passed 'bcreate undo_no_revs' test.


CR Number                     : 763
Short Description             : File is locked message not always getting back to user
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 10/22/93
Found in Baseline             : 2.3
Found Date                    : 10/22/93
Severity                      : C
Priority                      : 1
Status                        : fix
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 10/22/93 public]
If an rcs file is locked for ancestry updating, the server tool will report
'File is locked'. Not all b-tools pass this information along to the user.
For instance, bco has this problem.

[damon 11/20/93 public]
The 'file is locked' should be more descriptive. As it is it is misleading.
Change to something like "File is temporarily locked for ancestry update."

Programs that do not pass back the message:

bco
bmerge

[damon 11/22/93 public]
This was a combination of not relaying output from bmerge_s and branch_ci, and
not having a default verbosity level for the ui_print() routine.


CR Number                     : 756
Short Description             : version numbers are incorrectly increased
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 754, 735, 729
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : marcyw (Marcellena Wood)
Reported by Company           : osf
Interest List CC              : tom (Tom Jordahl)
Reported Date                 : 10/20/93
Found in Baseline             : 2.3
Found Date                    : 10/20/93
Severity                      : A
Priority                      : 0
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[marcyw 10/20/93 public]
The version numbers on files are being changed from 1.1.6.2 to 1.1.62.1.

ex: /test/systest/tools/gdsdirinfo.awk 1.1.9.1 to 1.1.91.1

GDS also has some extremely high numbers:

./directory/gds/msg/En/d20adm.msg       1.1.770.3       1.1.770.2

[damon 11/19/93 public]
This seems to have been fixed by the cleanup work done on ancestry:
CRs: 754, 735, 729

[damon 1/14/94 public]
This cropped up again. The circumstance was that a user submitted
to a static build ( which correctly submitted the file to latest ).

[damon 1/24/94 public]
This is worse than I had originally thought. Apparently, the large version
number is used by rcs, but the ancestry is changed in a different way. Thus,
the ancestry information is recorded wrong.

I have been unable to reproduce this bug by just using the tools. I am now
trying to purposely subvert parts of the code in order to reproduce it.

A symptom of this problem is that merges don't work properly. To fix this,
look at the user's file and determine the correct ancestry. Then, patch
the ancestry in the rcs file.

[damon 1/24/94 public]
This is now reproducible. As soon as you have a revision number with the
third field that is bigger than the following revisions, the problem will
occur. This does not happen on ODE 2.3.4 at386_osf1 client&server platforms,
but it has been shown to happen with ODE 2.3.4 at386_osf1 client and
ODE 2.3.3 hp700_hpux server:

./rat_test/1.sh 1.1.4.1 1.1.2.1
./rat_test/2.sh 1.1.2002.1      1.1.2000.1
./rat_test/3.sh 1.1.3003.1      1.1.2.1
./rat_test/4.sh 1.1.3004.1      1.1.2.1
./rat_test/5.sh 1.1.3005.1      1.1.2.1

[damon 1/24/94 public]
Reproduced with ODE 2.3.4 on both client/server for at386_osf1/hp700_hpux
combination.

[damon 1/24/94 public]
Wow! Wow! This was a bug from way back. It turns out that this has been
around since 2.0 when we replaced 'ci -b' with branch_ci. It didn't show up
because we have been using pmax_ultrix as our rcs servers... until recently.
Ultrix zeroes out all strings before use, so this problem didn't show up.
However, on hp700_hpux, strings are not zeroed before use. Here is the
offending code and solution:

    for (i=0, j=0, dots=0; latest_branch[i] != ';'; i++)  {
      if (dots >=2)
        bnum[j++] = latest_branch[i];
      if (latest_branch[i] == '.')
        dots++;
    }
/*
 * Add:
 */
    bnum[j] = '\0';

So why didn't this show up in our extensive testing of 2.3? Because we
used symmetric operations. When testing using large batches of files, all
files received the same operations in the same order. So, the number of
characters in bnum[] was always the same. We will need to add some
irregular operations in our test suite.

[damon 1/31/94 public]
Passed 'bsubmit large_branch' test.


CR Number                     : 747
Short Description             : user selectable ancestor for bco
Defect or Enhancement?        : enh
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : sommerfeld@apollo.hp.com
Reported Date                 : 10/18/93
Found in Baseline             : 2.3
Found Date                    : 10/18/93
Severity                      : C
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 10/18/93 public]
bco will have a new option, '-a <rev>' which will allow the user to check out
version <rev> and have <rev> be the ancestor of the user's branch.

[damon 1/4/94 public]
Passed 'bco ancestor_option' test.


CR Number                     : 736
Short Description             : mklinks confused by link in sandbox path
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 10/13/93
Found in Baseline             : 2.3
Found Date                    : 10/13/93
Severity                      : C
Priority                      : 3
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : ode/bin/mklinks/mklinks.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 10/13/93 public]
If a symbolic link exists in the path to the user's sandbox, mklinks complains:

>> FATAL ERROR in mklinks:
   directory given is relative; current directory not in sandbox.

For instance, I made a link /u0/damon -> /usr/users/damon and put in my
.sandboxrc 'base * /u0/damon/sandboxes'.

[marty 11/29/93 public]
Fixed!

[damon 1/21/94 public]
Gets beyond this complaint in test 'mklinks link_in_sb_path'. Test fails
for another reason, but this part is fine.


CR Number                     : 679
Short Description             : bsubmit exits quietly if ancestry info is garbled.
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 9/22/93
Found in Baseline             : 2.3
Found Date                    : 9/22/93
Severity                      : C
Priority                      : 3
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : damon (Damon Poole)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 9/22/93 public]
If the ancestry is garbled, like:

1.1.2.5>1.1.2.4;ad@ad@35t^G^H

bsubmit will exit quietly:

Submitting files
----------------
./1.sh
./2.sh

%
It is not clear how the ancestry information gets garbage at the end, but
bsubmit should fail better than this.

[damon 10/8/93 public]
Also happens if it is circular.

[damon 11/22/93 public]
The ancestry information is now validated as soon as it is acquired. Therefore,
no operation will operate on invalid ancestry information.

[damon 11/23/93 public]
The ancestry validation routine is a bit overzealous.

[damon 11/23/93 public]
Checking string for NULL instead of checking first char for '\0'

[damon 1/18/94 public]
Although the ancestry information is validated, this doesn't stop things
immediately. But, since the resulting information is bad, it is caught later
on. Still, anything calling src_ctl_get_ancestry() should stop right away if
an error is found.

[damon 1/19/94 public]
Fixed error handling.

[damon 1/21/94 public]
Passed 'bsubmit bad_ancestry' test.


CR Number                     : 667
Short Description             : Corrections in documentation.
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : marty (Marty Lynch)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 9/15/93
Found in Baseline             : 2.3
Found Date                    : 9/15/93
Severity                      : C
Priority                      : 3
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : ode/doc/sag/build.instl.tbl
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[marty 9/15/93 public]
This is for the ODE2.3 documentation.  Reported by Sean Mullan (HP).

1) Typo on p. 10, line 1 of Sys Admin guide :

     change /ode-path/rc_files to /ode-path/ode/rc_files

2) Typo on p. 9, last par :

     should be "Create a /ode-path/ode/.sandboxrc ..."

3) Paragraph 1 of p. 10 tells the administrator to set up the rc files
   in the directory /ode-path/ode/rc_files. It was unclear to me which
   rc files I needed to change, and how much pre-setup was already done.

   I ended up adding only one thing to ode/Buildconf :

     on hp700 setenv context hp700_hpux

   Also, the admin guide did not tell me what the "on" keyword means
   and what are valid system names.

4) In section 3.2 of admin guide, they repeatedly mention the script
    "cmds.sh" and having run it in a previous section. However, there
    is no mention of this script prior to section 3.2.

5) P. 10 of admin guide

    Change PATH="/ode-path/ode/tools/<context-name>>/bin:PATH" to
           PATH="/ode-path/ode/tools/<context-name>/bin:PATH"

6) p. 10 of admin guide

    3rd to last line

    Change "cd /ode-install-path/ode/src"
    To     "cd /ode-path/ode/src"

7) HP-UX specific problem. In order to build postscript version of
   System Administrator's Guide. modifications were made to
   src/ode/doc/sag/Makefile.generic :

   TROFF=psroff
   TROFF_FLAGS=-t
   POSTP=

[marty 12/23/93 public]
Corrections 1, 2, 4, 5, and 6 have been incorporated into the sag.
#7 is a site specific problem and will not be addressed.

[damon 1/28/94 public]
Reviewed, looks good.


CR Number                     : 663
Short Description             : ODE 2.3 needs 'bco -undo' back.
Defect or Enhancement?        : enh
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : Elliot_Jaffe@transarc.com
Reported by Company           : osf
Interest List CC              : zeliff (Rich Zeliff), drk (David Kaelbling)
Reported Date                 : 9/9/93
Found in Baseline             : 2.3
Found Date                    : 9/9/93
Severity                      : B
Priority                      : 2
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : src/ode/bin/bco/bco.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[marty 9/9/93 public]

Elliot has reported that the absence of 'bco -undo' is a big problem
for Transarc.  Currently, if you have a file that is checked out
from a branch and you want to undo the check out, their are two scenarios.
The first (if the branch has at least one edit applied to it) is to remove
(rm) the file from the sandbox (leaving the file in the set).  The second (if 
this is a check out from latest, no edits have been checked in and you want 
to get rid of the branch altogether) is to outdate with 'bcs -o'.

Elliot feels that both cases should be handled by the command 'bco -undo'.

the branch.

[ damon 9/11/93 public]
I have changed this to an enhancement request because this was planned. It
is not a defect. The reason for removing bco -undo is because it is a
continuing drain on user support resources. It did not do what people thought
it would do. It was the same as bcs -o. People have always been encouraged
to use bcs -o. The removal of bco -undo was the logical next step.

I believe that there is only one time when bco should be capable of doing
outdating. Hypothetically, bco -undo could check to see if the file has just
been checked out for the first time. If so, outdate the branch and remove
the file from the sandbox. In all other cases, complain.

What do people typically think bco -undo means? They think it means undo the
effect of the last bco/bci. It is not clear. In other words, if I have done
3 bcos and/or bcis, put me back to the state I was in after the 2nd bci/bco.
bco -undo has never done this.

However, it is more logical for bci to do outdating. bco -undo should not
be used to undo the effect of a bci. It doesn't make any sense.

Actually, probably the best thing to do would be to have bco -undo act as I
outlined in para 2 and make it easier to bco previously checked-in versions.

In any case, I think that this sort of a change should wait for a future
release in the interest of stability. We will be making more frequent
releases, so this should not be a big problem.

[ marty 9/13/93 public]
Actually, what Elliot was asking for was not "how to get rid of the
last check-in", but, "how to get rid of a file that is checked out".
Currently, the way it is done is either removing the file from your
sandbox or (if the user branch has only one revision on it) out
the branch altogether from you set.  Whether or not we use the "-undo"
switch to accomplish this; I really don't care.  The point is
the user currently needs to know more information about the files branch
than is necessary.

[ marty 9/15/93 public]

Here is the way I think that bco -undo should work:

1)   If the file has been checked out for editing and this
     was the first "bco" for this private branch then
     "bco -undo" do the same thing that "bcs -o" does;
     that is, it outdates the branch and removes the file
     from that sandbox as well as the .BCSset- file.

2)   If the file has been checked-IN (NOT checked out for editing)
     on a branch
     (that is, bco, bci, bco, bci, bco ... bci)
     then presumably "bco -undo" should do nothing.   There is no
     edits to "undo".  However, there is no way to be sure that
     the read-only copy of the file is the same as the revision on the
     end of the branch or if the user had done a "bco -read -r 1.2.3.4"
     of the same file.  The best thing to do is a "bco -read" off the
     end of the private branch.

3)   If the file is checked-out (for editing) after a series of 
     checkins and checkouts (bco, bci, bco, bci ... bco)
     then the file should be removed from the sandbox and 
     a "bco -read" of the end of the private branch should be done.

This way we can guarentee that the user will be seeing either
the file in the backing tree (by outdating the branch) of the
file at the "end"  of the branch.

[marty 11/22/93 public]
I have a fix in ODE2.3.4 for this.  Here is how 'bco -undo' behaves:

1) If this is the first 'bco' and the branch is newly created then
'bco -undo' will outdate the branch and remove the file from the sandbox and
print the message
"File <filename> is being outdated and removed."

2) If there have been any checkin's to the users branch then 'bco -undo'
will replace the file in the users sandbox with a read-only copy of 
what was last checked in and print the message:
"File <filename> has been replaced by the latest revision on your private branch."

I am marking this as fixed.  If anyone has any objections to the wording of 
the messages then we can open this up again.

[damon 12/29/93 public]
The following tests were added and passed:

bco undo
bco undo_after_bci
bco undo_no_user_branch


CR Number                     : 657
Short Description             : mklinks confused by sandbox setup
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : pshaw (Peter Shaw)
Reported Date                 : 9/9/93
Found in Baseline             : 2.3
Found Date                    : 9/9/93
Severity                      : D
Priority                      : 3
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : 
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[damon 9/9/93 public]
mklinks seems to be confused by the /.../ in a dfs pathname. It complains
that the path is relative.

[damon  9/9/93 public]
Actually, mklinks worked fine in a new sandbox. It is getting confused by
something in pshaw's dce103 sandbox on pedro in /.../sisyphus.osf.org/fs/users/pshaw/dce103

It gives:

>> FATAL ERROR in mklinks:
   directory given is relative; current directory not in sandbox.

[marty  9/9/93 public]
This problem comes about when in your .sandboxrc file you specify the base as
/.../sisyphus.osf.org/fs/users/pshaw/
instead of 
/.../sisyphus.osf.org/fs/users/pshaw
When mklinks builds up the pathname of "where your current directory is"
it will get 
/.../sisyphus.osf.org/fs/users/pshaw//dce103/src
instead of 
/.../sisyphus.osf.org/fs/users/pshaw/dce103/src

There is a routine in libode that checks to see that you are in a sandbox
before doing any b-tools operations.  This routine thinks that the above two
pathnames are different and hence prints out an error.  This routine should
be changed to strip out extra "/"'s in pathnames.  

In the mean time, people can change thier ./sandboxrc files so that multiple
"/"'s don't show up.

[marty 11/29/93 public]
Fixed along with OT # 736.

[damon 1/28/94 public]
Passed 'mklinks extra_slash' test.


CR Number                     : 654
Short Description             : 'make' should not depend on "/usr/bin/sh".
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : sommerfeld (Bill Sommerfeld)
Reported by Company           : hp
Interest List CC              : sommerfeld@apollo.hp.com, burati@apollo.hp.com, mario (Mario Moreira), dce_sec_dev@ch.hp.com, marcyw (Marcellena Wood)
Reported Date                 : 9/7/93
Found in Baseline             : 2.3
Found Date                    : 9/7/93
Severity                      : C
Priority                      : 3
Status                        : fix
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : ode/bin/make/job.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : 
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[marty 9/7/93 public]
I know that there has been some internal talks about how this should
be handled.  Here is how the people from HP feel about it.  Any comments?

> From sommerfeld@apollo.hp.com Tue Sep  7 15:48:45 1993
> Date: Tue, 7 Sep 93 15:47:30 -0400
> From: Bill Sommerfeld <sommerfeld@apollo.hp.com>
> To: Marty Lynch <marty@osf.org>
> Cc: Sean Mullan <mullan_s@apollo.hp.com>, Rich Zeliff <zeliff@osf.org>,
>         Larry Derany <larryd@apollo.hp.com>
> Subject: problem with ode 2.3.2 on HP-UX.
> 
> ode/src/bin/make/job.c contains the following:
> 
> 	/*
> 	 * The command contains a shell "meta" character and we therefore
> 	 * need to pass the command off to the shell. We give the shell the
> 	 * -e flag as well as -c if it's supposed to exit when it hits an
> 	 * error.
> 	 */
> 	if (argc == 1) {
> 	    argv[0] = "/usr/bin/sh";
> 	    argv[argc++] = "sh";
> 	} else
> 	    argv[argc++] = "/usr/bin/sh";
> 	argv[argc++] = (errCheck ? "-ec" : "-c");
> 	argv[argc++] = cmd;
> 
> "/usr/bin/sh" does not exist on HP-UX, or, for that matter, on most
> UNIX systems where /bin is not a link to /usr/bin .
> 
> "/bin/sh" is the canonical hard-coded location for the default,
> minimal shell.
> 
> The special-case code for argc==1 looks somewhat bogus to me as well.
> 
> Creating a symlinnk from /usr/bin/sh to /bin/sh is not an option for
> us, as we need to run this code on ~50 different developer
> workstations and lab machines; it's far easier for us to just whack
> the source code than to create symlinks on every single machine.
> 
> 					- Bill

[bowe 12/23/93 public]
It is idiotic to have "/usr/bin/sh" be the only shell invoked across all
platforms.  All machines have a "/bin/sh", which is the most portable. 
True, "/usr/bin/sh" is the posix place for it.  But using a strictly
posix-conformant application (if ODE were, that is) on a non-conforming
system will only cause problems in many cases.

The better solution is to try /usr/bin/sh, and if not there, usr /bin/sh.
Or make it user-settable (thru env variable of Buildconf file).

[damon 1/31/94 public]
Gee, what do you really think? :-)
Actually, we don't have to conform to posix because our make is not the
make shipped with OSF/1. And, we are not responsible for the OSF/1 make.
I like the idea of getting 'sh' from an environment variable. That way,
projects can control which 'sh' is being used. This is important because
'sh' can be considered to be an integral part of make.

I suggest that make look for the variable 'MAKE_EXEC_PREFIX' first. If it
doesn't find it, make should then try /usr/bin/sh, then /bin/sh. If
MAKE_EXEC_PREFIX is not found, but /usr/bin/sh or /bin/sh are, then make
should set MAKE_EXEC_PREFIX accordingly to assure that future execs of
make all use the same shell and don't have to search for 'sh' again.

[marty 3/11/94 public]
I changed the hardwired path "/usr/bin/sh" to just "sh".  I tested it on an
hp700 and it seems to work just fine.


CR Number                     : 629
Short Description             : errors in ODE User's Guide
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : doc
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : rsalz (Richard Salz)
Reported by Company           : osf
Interest List CC              : rsalz (Richard Salz)
Reported Date                 : 8/27/93
Found in Baseline             : 2.3
Found Date                    : 8/27/93
Severity                      : C
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : src/ode/doc/users.gd
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[rsalz 8/27/93 public]
Some errors found in the ODE User's Guide.  I tried to avoid typo-level
errors and just things that I found jarring.  Can you snag a doc person
to read the DUG and comment some time?

Applicability, page ii, says accurate to ODE2.1.  I was hoping for 2.3 :-)

The word Italic, page iii is in bold and should be in italics.

Page iii says the book does not fully conform to the typographic
conventions.  If it doesn't, it should.  If it does, delete the sentence.

Page iv says "Release Engineering and Distribution" is that an old name for
RaT?

Page 1 says there is a DCE supplement to DUG.  I don't think there is one.

"There are three basic areas" should be "The three basic areas"

The first two paragraphs on build environment, page 1, should be merged.
The third paragraph has the same first and last sentence.

Page 2, 1.1.1 Terminology.  The "or..." could be written as "a build"
or "the build."  For "set" definition use "as a unit" instead of "as a
whole."  A backing three is a build+libs and tools?

Page 8, 2.5.1 creating sandboxes.
Do you want to say that mksb also creates a "link" pointing to backing build?

I think you shoould remove and simplify the restriction list.  E.g., you
can only create one at a time can be stated only on the manpage.  Remove
the reason for why you cannot have two sb's with the same name.  Delete last
item on that page (symlink discussion) altogether.  You have two many
nitty-gritty details for an intro section.

2.5.3 Populating a sandbox
First para, last two sentences:  make into one sentence.
Second para ,"setting up links and physically copying" s/and/or/.

Page 11, last line "false." is missing.

Page 12, 3.  There isn't a tutorial, just the set stuff.

Page 12, 3.1. "rcs" should be written as RCS.
Page 12, 3.2.  You should mention the flag/argument rules "-m 'te asdas'" not
"-m'te asdas'" for example.

Page 13, the prototype .c and Makefile are mostly in the wrong font.
The "If a file type does not" sentence should be joined into the next one,
which is a sentence fragment.  After mentioning "bcreate -undo" do you
want say "bci -defunct"?

The end of p13 and the top of p14 seem redundant.  Move the "Be warned" to
end of p14 and delete rest of that paragraph?

Page 14, 3.2.3 "you can check out a file" but next para "prompts the user"  Pick
either first or third person, throughout.

Page 15, I'm unclear on outdate.  Do I do a "bci" before doing the "bcs -o"?
The example for making a file defunct should include the bco step.

Page 16, 3.4  Private sandboxes are all lowercase?  Really?  If so, this
should be moved to sec 2.5.1

Page 17 "bco -set xxx -all" Do I need the -all?  Isn't that implied by -set?

Page 18, build environment.  You say "build does this" when isn't all the
work really done by the ODE make?

I think a picture and "ls" for 4.1.2 would be helpful before the listings.

Page 27; is 4.4.6 a duplicate of 4.4.3?

Page 29, 4.4.9.  Is OPT_LEVEL an envir var, a sandbox rc_files var, or what?

Pages 29 and 25; shoud 4.4.1 move to just before 4.4.10?

Page 30, 4.4.11 "install" is in wrong font in sub-section title

Pages 35-36:  should the last few paragraphs just be flushed in favor
of "see a Release Engineer"?

Somewhere, there needs to be discussion of how HISTORY entries can get
auto-merged into $Log: change_requests,v $
NONERevision 1.1.7.2  1994/03/14  19:43:21  damon
NONE	CR 245. Added more CRs
NONE
NONERevision 1.1.8.2  1994/03/14  19:43:04  damon
NONE	CR 245. Added more CRs
NONE
# Revision 1.8  94/01/28  11:02:26  ot
# changed fields: Status   new/changed/deleted note(s) [damon 1/28/94 public]
# 
# Revision 1.7  93/12/15  17:24:07  nata
# added the Created HISTORY line
# 
# Revision 1.6  93/11/18  16:42:39  ot
# changed fields: Status  Fix By Baseline  Fixed In Baseline  Affected File(s)  
# 
# Revision 1.5  93/11/18  11:31:10  ot
# changed fields: Priority  
# 
# Revision 1.4  93/09/22  10:27:18  ot
# changed fields: Fix By Baseline  
# 
# Revision 1.3  93/09/02  10:29:30  ot
# changed fields: Responsible Engr.  Resp. Engr's Company  
# 
# Revision 1.2  93/08/27  15:17:57  ot
# changed fields: Interest List CC   new/changed/deleted note(s) [marty 8/27/93 public]
# 
# Revision 1.1  93/08/27  15:00:42  ot
# new CR
#  entries -- where I enter them, what they look
like, etc.

[marty 8/27/93 public]
Rich, we'd appreciate more details in the future ;-) ... just
kidding!

Actually, we had done a quick update of the ODE documentation
a few days ago and many of the problems you mentioned have already
been fixed.  Unfortunately, the copy you got must have been
printed last week.  To get another copy, type this command:
lpr -Paxle /project/ode/tools/ode2.3/at386_osf1/doc/sag.ps
and
lpr -Paxle /project/ode/tools/ode2.3/at386_osf1/doc/UsersGuide.ps

We will probably be incorporating the rest of you suggessions
into the Docs next week.

Thanks for the comments!

[damon 1/28/94 public]
Reviewed, looks good.


CR Number                     : 628
Short Description             : make manpage missing .tryinclude
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : doc
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : make
Reported by                   : rsalz (Richard Salz)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 8/27/93
Found in Baseline             : 2.3
Found Date                    : 8/27/93
Severity                      : C
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : src/ode/man/man1/make.1
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[rsalz 8/27/93 public]
The make manpage does not mention the 2.3 .tryinclude facility.

[marty 11/18/93 public]
It does now.

[damon 1/28/94 public]
Reviewed, looks good.


CR Number                     : 623
Short Description             : man pages need updating
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : marty (Marty Lynch)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 8/24/93
Found in Baseline             : 2.3
Found Date                    : 8/24/93
Severity                      : C
Priority                      : 3
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : ode/man/man5/oderc.5
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[marty 8/24/93 public]

[damon 9/22/93 public]
oderc is the only thing left needing updating.

[marty 12/15/93 public]
Done.

[damon 1/28/94 public]
Reviewed, looks good.


CR Number                     : 599
Short Description             : bcreate ALWAYS queries user when non-standard comment leaders have been specified on the command line.
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : marty (Marty Lynch)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 7/6/93
Found in Baseline             : 2.3
Found Date                    : 7/6/93
Severity                      : C
Priority                      : 3
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : bcreate.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[marty 7/6/93 public]
I though this was fixed.  Apparently when the user specifies a non-standard comment leader
on the command line they are queried as to whether the comment leader was right even if they
specify the "-auto" switch.
There should be a way ("-auto" or "-fast") to specify the comment leader on the command
line and NOT get queried.

[marty 12/23/93 public]
Fixed.

[damon 1/27/94 public]
Passed 'bcreate non_std_leader' test.


CR Number                     : 540
Short Description             : mklinks doesn't work on first level directory in sandbox.
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : marty (Marty Lynch)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 5/25/93
Found in Baseline             : 2.3
Found Date                    : 5/25/93
Severity                      : C
Priority                      : 3
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : ode/bin/mklinks/mklinks.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[marty 5/25/93 public]
Fixed.

[marty 6/8/93 public]
broken on hp700_hpux

[marty 6/9/93 public]
Turns out that if you build this "optimized" then the hp compilers remove
just a little too much code.  The Makefile has been changed to turn off
optimization and everything works fine  now.

[damon 12/29/93 public]
This should be re-attempted with optimization not turned off. Turning off
optimization is not a good way to fix things. It usually means that there is
a variable that is not initialized.

[marty 1/11/94 public]
I wish I'd written down more specifics on how to reproduce this.
I can't seem to reproduce this problem on an hp (zagrev).   I've tried
rebuilding (with optimization turned on) for ode2.3.2 ode2.3.3 and 
ode2.3.4.  Not sure what the problem was.  Oh well, I write a test case for 
it anyway.  I'll remove the OPT_LEVEL definition from the mklinks Makefile.

[damon 1/21/94 public]
Passed 'mklinks simple' test.


CR Number                     : 234
Short Description             : No "bco -p" switch
Defect or Enhancement?        : enh
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : all
S/W Ref Platform              : all
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : rsalz (Richard Salz)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 7/16/92
Found in Baseline             : 2.1.1
Found Date                    : 7/16/92
Severity                      : C
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : sci.c,sci.h, bco.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[rsalz 7/16/92 public]
bco should take a -p switch, analogous to "co -p" that sends output
to stdout.  It should (obviously?) for the "-u" switch.

[marty 11/22/93 public]
bco now supports the "-p" option when checking out files "read-only".

[damon 12/30/93 public]
Added test 'bco stdout' which passes.


CR Number                     : 108
Short Description             : -query does dir by dir not file by file
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : pmax
S/W Ref Platform              : osf1
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 10/31/91
Found in Baseline             : 2.1
Found Date                    : 
Severity                      : C
Priority                      : 1
Status                        : closed
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : ode/bin/mklinks/mklinks.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[ damon 10/31/91 public ]
As the following output shows, this command queries on a dir by dir basis.
The man page entry for -query states: "...query the user for EACH file..."
Capitalization mine.

nomad 232 ] mklinks -verbose -query -cmp .
>  Reading rc file : /usr/users/damon/.sandboxrc
>  linking: /usr/users/damon/sandboxes/man_test/link/src/.
   to     : /usr/users/damon/sandboxes/man_test/src/.

Comparing directory subtree:
      /usr/users/damon/sandboxes/man_test/link/src/.
  to: /usr/users/damon/sandboxes/man_test/src/.

Is this correct?  [yes]
Link directory ./ode ?  [yes]
>  ./Makeconf: created
>  ./kxct.conf: created
>  ./.temp_prefix: created
Link directory ./rat_test ?  [yes]
>  ./rat_test/gghh.c: created
>  ./rat_test/fhfhf.c: created
>  ./rat_test/1.sh: created
>  ./rat_test/2.sh: created
>  ./rat_test/3.sh: created
>  ./rat_test/bcs-test.c: created
Link directory ./mckeen ?  [yes]
Link directory ./usr ?  [yes]

[damon 6/19/92  public ]
Perhaps we just need to change the documentation?

[marty 12/14/93 public]
Fixed.  Now performs as documented.

[damon 1/21/94 public]
Passed 'mklinks query_option' test.


CR Number                     : 70
Short Description             : mklinks -copy doesn't preserve execute permission
Defect or Enhancement?        : def
CR in Code, Doc, or Test?     : code
Inter-dependent CRs           : 
Project Name                  : ode
H/W Ref Platform              : pmax
S/W Ref Platform              : osf1
Component Name                : src
Subcomponent or Book Name     : 
Reported by                   : damon (Damon Poole)
Reported by Company           : osf
Interest List CC              : 
Reported Date                 : 10/11/91
Found in Baseline             : 2.0.2
Found Date                    : 
Severity                      : C
Priority                      : 1
Status                        : fix
Duplicate Of                  : 
Fix By Baseline               : 2.3.4
Fixed In Baseline             : 2.3.4
Affected File(s)              : ode/bin/mklinks/mklinks.c
Responsible Engr.             : marty (Marty Lynch)
Resp. Engr's Company          : osf
Sensitivity                   : public
How was this defect found?    : other
Customer Support Ticket Number: 
Reported by Company's Ref. Number: 

[ damon 10/11/91 public ]

When using mklinks to copy objects and binaries, execute bits should be
set properly.

[marty 12/14/93 public]
Fixed.


