Re: [Bug-cssc] bug-CSSC post from address@hidden requires approval

[James Youngman]

On Sat, Apr 30, 2011 at 8:59 PM, Joerg Schilling
<address@hidden> wrote:
> James Youngman <address@hidden> wrote:
>> - differences in the format of the header printed by sccsdiff (both
>> between vendors and IIRC between Solaris 2.6 and 8).
>
> Are you talking about the optical differences in the output?

>From the CSSC documentation:


6.9.2 sccsdiff
--------------

There are some small variations in the way that the several versions of
`sccsdiff' behave.  These are outlined in the table below :-

Solaris 8
     Prints a separator line between the `diff' output for each s-file.
     This separator is output before the first set of diff output,
     even if only one s-file has been named on the command line.

Solaris 2.6 and many other versions of Unix
     Does not print a separator.



>> - some implementations (ncluding Dynix) accept "admin -ifoo -n" and
>> reject "admin -n" alone.
>
> Dynix is dead for many years and I am sure that few people use admin 
> separately
> at that level. I even suspect that there is no y2000 compliance in that SCCS
> implementation and people would better upgrade to a recent SCCS.

Yes.    There's likely no "live" interoperation possible here, I doubt
there are more than a couple of Dynix systems still running anywhere.

>> - some implementations don't allow a level to be specified with "admin -r".
>
> This may be a bug
>
>> - I believe some (quite old) implementations lack prt
>
> prt was part of sccs since the beginning. Some vendor variants (e.g. IBM, SGI,
> HP) do not include it - maybe because it is not mentioned by POSIX and because
> there is prs.

My apologies.   I meant prs, which was written by Charlie Salemi in
response to a stream of requests to modify the output of prt.

>> > The POSIX standard does not specify the SCCS history file format and I 
>> > believe
>> > that this helps to introduce extensions without breaking POSIX compliance.
>> > Are there other things you believe to be missing in the POSIX standard?
>>
>> A description of the semantics of included, excluded and ignored
>> deltas is clearly missing.   As are countless other things.
>
> The POSIX get documentation includes -x and -i
> The POSIX delta documentation includes -g
>
> What are you missing?

Mainly a comprehensive description of how these three things interact.

> What other things do you have in mind?
>
>> Including I suppose a more subtle point, a clear description of what
>> it means in the various places where it says "recent" or "newer".
>> There are a number of places where the behaviour of SCCS depends on
>> the order of deltas in the history file header, as opposed to the
>> sequence numbers or SIDs.   While these are usually consistent, it
>> doesn't always have to be so.
>
> Maybe this is a result from the fact that POSIX did just start with the UNIX
> man pages and that the history file format description is not 100% complete
> and even missing in the POSIX standard?
>
> If you have proposals to make things better, we could fix the POSIX standard.
>
> At least POSIX prs mentions sequence numbers. As sequence numbers are just a
> low level notation, it should be OK to describe the behavior based on SIDs.
>
> Do you get different l-files with various get implementations when using the 
> -l
> option?

I don't think the test suite checks that and so there could be
infinite variation from all I'd know.  But I don't recall receiving
any bug reports on this subject.

>> >>  %sccs.include.filename%        Lines are replaced by the content from 
>> >> filename
>> >
>> > as the lowercase characters have a high probability to become in conflict 
>> > with
>> > printf, they are disabled unless the 'x' flag is present.

I forgot to ask: what's the intent for when the sccs binary is
installed separately as a setuid binary (usually for providing
controlled access to a project repository)?   Presumably if sccs was
setuid,  %sccs.include.filename% would need either to be ignored or
perhaps would need to be processed after privileges are dropped.

>> So there are two different interpretations of the 'x' flag?   That's
>> entertaining.   Thank you for choosing a distinctive non-zero value,
>> since this allows us to distinguish your extension from the SCO
>> extension.
>
> In any case, when it is not 100% granted that development is completely
> aligned, it is a good idea to add a vendor tag. See the tar format extensions
> started 1997 by Sun and standardized 2001 by the OpenGroup as a good example
> and ZFS as a bad example.
>
>
>> >        ^A f *
>> >
>> > is related to %sccs.include.filename%
>> >
>> > A longer documentation is available with "man get".
>>
>> It's not in the manpages I looked at (SunOS 5.11 and SCCS-1.0).
>> Searching we web I found http://sccs.berlios.de/ which mentioned but
>> doesn't document the feature.
>
> It was only available on *BSD, but it seems to be very useful in special if
> someone likes to use it for license headers. So I fetched the code from BSD
> Unix.
>
>> (fwiw, looking at that page, it mentions "admin -fe" which should be
>> "admin -b" since "-fe" won't work [SCCS should complain that the e
>> flag is unknown, though really it isn't]).
>
> Could you give me the exact place please?

"""
What are the advantages of SCCS?

SCCS is the first version control system, originally written in 1972
by Marc J. Rochkind at Bell Labs
No known "SCCS caused" data loss since at least 30 years
One Source file results in one SCCS history file
Easy to understand format of the history files that allows manual intervention
Checksums and forward deltas (weave file format) grant file integrity
and immediate detection of corruption
Forward deltas (weave file format) allow fast extract by using a
single linear read on the history file
Support for binary files using uuencoded SCCS history (set up via admin -fe)
"""

The final line above.


>> I think the most accurate answer I can give here is yes, but clearly
>> it's possible for there to be exceptions.  If the CSSC user base is
>> interested in using a feature, or needs to interoperate with it, I'm
>> likely to implement it.
>
> Do you know what this user base is?

Pretty small, I'm guessing.   But I have no idea of numbers.


>> Some versions of SCCS also permit a ':' in the tens digit of the year,
>> but I can't offhand think of a way of making use of this, since
>> there's a well-defined interpretation (":0" is written by some
>> y2k-broken implementations where "00" should have been used).
>
> s/permit/incorrectly produce/

Certainly it's incorrect to produce it.   But I specifically meant
"permit".  In the sense that some implementations recognise the
incorrect representation and fix it when editing the file.

> This looks like the well known unfixed Y2k bug in SCCS versions from before
> 1999.

Yes.


>> CSSC does have CSSC-specific changes to the sccs binary, but the
>> purpose of those changes is to allow CSSC's "sccs" binary to forward
>> operations to the CSSC binaries (admin, get, etc.) rather than by
>> accident to the SCCS ones.   That is, the idea is to prevent
>> conflicts.
>
> If you first install CSSC and this installs /usr/bin/sccs and later install
> SCCS, the /usr/bin/sccs that you have then is the progrsm from SCCS.

Yes, that would be a bad decision on the part of the system
administrator or the packaging system.

James.