(I now realise that I sent this to the review list, but not to
yyyyyyyyyyyy@xxxxxxxxxxxxx, and now reliase that common practice is to
send to both. Sorry.)
@ Page 2340 Line 4722 Section admin Comment [ukuug-d5-j1]
Problem:
The specification for the behaviour of the -r option implies that a level
number is to be supplied. This is not the case. The number to be supplied
is the SID of the initial delta in the file. This can include a level
number as well as a release number. For example, 4.6 is a valid argument to
the -r option.
Action:
Change "-r rel" in the left column of line 4722 to "-r SID".
Change the text of the paragraph which follows to :-
Specify the SID of the initial delta to be inserted. This SID shall
be a trunk SID; that is, the branch and sequence numbers shall be zero
or missing. The level number is optional, and defaults to 1.
Append to the discussion of the "n" flag, after line 4768 on page 2341,
During the initial creation of an SCCS file, the n flag may be
ignored. That is, if the -r option is used to set the release number
of the initial SID to a value greater than 1, null deltas need not be
created for the "skipped" releases.
@ Page 2522 Line 11817 Section delta Comment [ukuug-d5-j2]
Problem:
Discussion of the -y option talks about an "unescaped newline" without
revealing what the escape character is. This page should specify it.
Action:
Add at line 11817,
The escape character is <backslash>.
@ Page 2523 Line 11854 Section delta Comment [ukuug-d5-j3]
Problem:
Just saying "default" is slightly misleading. Although delta does
indeed catch normally-fatal signals and do cleanup before exiting,
existing implementations don't re-signal themselves, they just exit.
Consider this example from Solaris 2.6:-
$ delta s.foo ; echo return value is $?
MRs? ^Creturn value is 1
$
A similar scenario may apply with many of the other SCCS tools, but
since most of them don't prompt for input, it is harder to catch them
with a signal, so I can't say for sure.
Action:
Change "Default" to "If SIGINT is caught, temporary files shall be
cleaned up and delta shall exit with a non-zero exit code."
@ Page 2523 Line 11832 Section delta Editorial [ukuug-d5-j4]
Problem:
"mrlist or a command" should be "mrlist or a comment", since the -m option
introduces an MR list and the -y option introduces a comment.
Action:
In line 11832, change "command" to "comment".
@ Page 2523 Line 11833 Section delta Comment [ukuug-d5-j5]
Problem:
Use of "-" as file argument is incompatible with the the use of STDIN
to accept MR lists and comments. An example error message given by one
SCCS implementation is :-
"ERROR: standard input specified w/o -y and/or -m keyletter (de16)"
This should be pointed out or defined by the document.
Action:
After line 11833, add
"In this case, the -y option must be used to specify the comment,
and if the SCCS file has the v flag set, the -m option must also
be used to specify the MR list."
At line 11800, after 'If -m is not used', add the words 'and "-" is
not specified as a file argument'.
At line 11814, after 'If -y is not specified', add the words 'and "-" is
not specified as a file argument'.
@ Page 2685 Line 18086 Section get Comment [ukuug-d5-j6]
Problem:
SID ranges are underspecified. The discussion of the <range> on line
18083 doesn't indicate what combinations are valid. The remarks in lines
18084 to 18086 would appear to imply that any valid SID is accepted, but
this is not the case. I am not aware of the full extent of the conditions
applied to this, but I know that at least, if the SID specified after the
'-' is on a branch, the SID specified on the left of the '-' must be one of its
ancestors. Disobeying this rule results in an error message. Viz:-
$ get -i"1.3.2.4" s.foo
Included:
3.1
1 lines
No id keywords (cm7)
$ get -i"1.3.1.1-1.3.2.4" s.foo
Included:
ERROR [s.foo]: bad range (co12)
Action:
Add at line 18086:
The SID on the left of the '-' must be an ancestor of the SID on the right
of the '-'.
@ Page 2685 Line 18086 Section get Comment [ukuug-d5-j7]
Problem:
Contrary to the statements in lines 18084 to 18086, I can find no evidence that
partial SIDs are used to select SIDs according to the rules laid out in
EXTENDED DESCRIPTION. For example (Solaris 2.6) :-
$ get -i"1.3.2.3" s.foo
Included:
1.3.2.3
3.2
4 lines
No id keywords (cm7)
$ cat foo
hi
This line added in 3.2
This line added in 1.3.2.3.
$ get -i"1.3.2" s.foo
Included:
3.2
2 lines
No id keywords (cm7)
$ cat foo
hi
This line added in 3.2
$
Action:
Delete lines 18084 to 18086.
@ Page 2689 Line 18255 Section get Comment [ukuug-d5-j8]
Problem:
If one or more of the deltas in the SCCS file appears to have been
created in the future, some implementations of SCCS will fail to
retrieve the lines added in that delta. Likewise, they may fail to
omit lines delted in that delta. This kind of problem only occurs if
the SCCS file has been modified by hand (in which case it serves the
perpetrator right) or if the system clock has ever been put back
(i.e. while the clock was 'forward', a new delta was checked in).
This kind of thing is quite common in certain kinds of software
testing, in which the behaviour of the system at some future date is
tested.
A similar apparent effect can be created by the use of environment
variables controlling the local time zone, because the times stored in
the SCCS file are in local time.
Action:
1. (get) Add a new subsection "System Date and Time" before line 18256
on page 2689. The text of this subsection should be :-
When a g-file is generated, the creation time of deltas in the SCCS
file may be taken into account. If any of these times are apparently in
the future, the behaviour is unspecified. This situation can arise
if the system date and time have been modified (for example put
forward and then back again) and can also arise through use of the TZ
environment variable when the delta utility is invoked on an SCCS
file.
Problems of a similar nature can also arise for the operation of the
delta utility, which compares the previous file body against the
working file as part of its normal operation.
2. (delta) Add a new subsection "System Date and Time" within the
(currently empty) "EXTENDED DESCRIPTION" section of the delta utility.
The text of this subsection should be :-
When a delta is added to an SCCS file, the system date and time is
recorded for the new delta. If the system date and time is
manipulated in such a way as to set the system date and time back to
a value which is apparently before a time recorded in an SCCS file,
the delta and get utilities shall behave in an unspecified way for
that SCCS file. A similar situation can be brought about through the
use of the TZ environment variable.
3. (delta) Add at the foot of the ENVIRONMENT VARIABLES section for
the delta utility (near line 11852), an entry for the environment
variable TZ. Add as the text for this entry:-
Determine the timezone in which the date and time of the creation of a
delta is recorded within the SCCS file (the creation time of deltas is
recorded in local time).
4. (date) On page 2510, add at the foot of the APPLICATION USAGE
section for the date command (near line 11415), the following text :-
Setting the system time and date back by a significant amount can
cause unexpected behaviour on the part of some programs, for example
the get utility.
@ Page 2954 Line 28621 Section prs Objection [ukuug-d5-j9]
Problem:
Description of keywords :Li:, :Ld:, :Lu: (and by implication :DL:)
is incpomplete. These figures are capped at 99999.
Action:
Add after "nnnnn" in the Value column of the table (on each of lines
28623-28625), for each item, the footnote symbol "***". Add after the
foot of the table (near line 28680 on page 2955), the following note:-
*** The line statistics are capped at 99999. For example, if 100000
lines were unchanged in a certain revision, :Lu: shall produce the
value 99999.
@ Page 3038 Line 31775 Section sact Comment [ukuug-d5-j10]
Problem:
The effect of 'get -e' can be reversed also with 'unget' and 'sccs unedit'
as well as 'delta'. This is not pointed out by the specification of
'sact'.
Action:
Change line 31775 from
a subsequent execution of delta
to
a subsequent execution of delta, unget, or sccs unedit.
--
James Youngman
Manchester, UK. +44 161 226 7339
PGP (GPG) key ID for <yyy@xxxxxxx> is 64A95EE5 (F1B83152).
|