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

[Joerg Schilling]

James Youngman <address@hidden> wrote:

> address@hidden (Joerg Schilling) wrote:

> > what it the purpose of the CSSC implementation? Is it just for fun or is it
> > intended to be valuable for dayly use?
>
> It's intended for daily use.   In fact, it's been in daily use for 14
> years or so.

I am asking this because I am using sccs on a daily base since more than 25 
years and I of course use sccs to keep the revision history for sccs. From 
looking at your project, I get the impression that you do not use cssc to keep 
the revision history for cssc. Is there something I am missing? Do you use cssc 
for real projects?

> > It is intended to be fully compatible to SCCS?
>
> It depends on how you mean; there are a number of different versions
> of SCCS which differ slightly.   It's intended to be useful for people
> trying to interoperate with those implementations of SCCS.   In
> practice this normally means implementing the union of those features.

I am not aware of noticable differences between the various implementations 
from UNIX vendors - of course there might be bugs. In fact, all UNIX vendor
implementations go back to the AT&T implementation from 1972. The major 
differences are some (propably even at Sun no longer existent extensions for
NSE from 1986) minor flag additions (e.g. Sun's 'y' and 's') and a major rework 
from Sun that introduced support for unlimited line length.

The most important new implementation from a UNIX vendor since 1977 seems to be 
the sccs wrapper program from Eric Allman.


> > Is it intended to be compatible to the POSIX standard?
>
> In a word, yes.   But there are a many things of course that the POSIX
> standard doesn't specify.

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?


> > I just found the following oddities with "val" from CSSC:
> >
> >
> > Testing with files created by a standard UNIX SCCS, I get the following 
> > problem:
>
> There is no single standard "UNIX SCCS".   Various implementations are
> (I'm guessing) forks.   With some small modifications.

I am not aware of differences between UNIX vendors that would really affect 
compatibility. This is mainly a result of missing developement since more than 
20 years. The Sun TeamWare project (a successor for NSE) resulting from the 
fact that SunOS has been the only OS that supported the translucent filesystem
has been introduced as a front end to sccs and as it has been in use for the 
CDE development by the related vendors, I am sure that there was no interest 
between UNIX vendors to introduce important deviations.


> > val: sccs/help.d/SCCS/s.cmds: line 31: Corrupted SCCS file. (Unknown flag 
> > 's'.)
> >
> > ... the 's' flag has been present on Solaris since quite a while.....
> >
> > Out of curiosity: the new 'x' flag is not mentioned by your "val"
> > implementation if present in a SCCS history file.
>
> Yes.  The 'x' flag is from SCO SCCS.   I'm not sure what you're
> suggesting val should do differently here.

Thank you for pointing to this problem. It is a long time since I used the SCO 
sccs (aprox. 10 years) and it seems that it is too long that I read the 
related man page. The 'x' flag as used by SCO however seems to be useless 
as SCCS has a better way to deal with the execitable bit on files: Just 
chmod +x SCCS/s.somefile 
This is more intuitive.

It seems however that I should ignore the 'x' flag in case that it has not been 
added together with the "SCHILY" argument.

>
> > With a SCCS history file created on UNIX 25 years ago, I get:
> >
> > val: libndbm/SCCS/s.dbm.h: line 35: Corrupted SCCS file. (Missing arg)
> >
> > just for an empty comment line...
>
> It looks like later versions of SCCS reliably include the space after
> the 'c' introducing the comment line.   CSSC's val therefore checks
> for this, since in the absence of any definition of the file format,
> I've relied on the features SCCS implementations seem to have in
> common (including this trailing space).     Since I guess you're now
> pointing out that not all SCCS implementations include a space here,
> I'll adapt the code.   Fully correcting this means understanding
> whether any implementations attempt to preserve such a feature.   Do
> you know of any implementations which insert such a comment into a
> delta?

No, but it seems that all implementations accept a comment starter without a
following space. This is why Larry VcVoy used it to add his extensions. 

> I think including an example as a test case would be helpful too.
> I've attached a program which removes everything from the SCCS file
> except its structure.   Could you try running it on your example and
> send me the result?

This is from the CSRG archives, so it is publically available.

> > Testing with files created by a recent SCCS, I get the following message:
> >
> > val: warning: The 'y' flag specifies a keyword letter '*', but %*% is not a 
> > recognised SCCS keyword
> > val: warning: The 'y' flag specifies a keyword letter 'd', but %d% is not a 
> > recognised SCCS keyword
> > val: warning: The 'y' flag specifies a keyword letter 'e', but %e% is not a 
> > recognised SCCS keyword
> > val: warning: The 'y' flag specifies a keyword letter 'g', but %g% is not a 
> > recognised SCCS keyword
> > val: warning: The 'y' flag specifies a keyword letter 'h', but %h% is not a 
> > recognised SCCS keyword
> >
> > These are keywords that have been introduced 3 years ago (well the flag 'y'
> > parameter '*' really relates to %sccs.include.filename% - a more than 20 
> > year
> > old extension added in April 1990 by Keith Bostic).
>
> The y flag was introduced into Solaris 8, I think.    But with all
> these extra keywords, it looks like we have some implementation work
> to do.   What do those keywords expand to?

>From "sccs help get_kywds":

        List of ID Keywords Recognized by the get Command

  ID          Value
Keyword       Type

 %A%          Shorthand notation for an ID line with %Z%%Y%  %M%  %I%%Z%
 %B%          SID branch component
 %C%          Current line number
 %D%          Current date: yy/mm/dd
 %d%          Current date: yyyy/mm/dd
 %E%          Date newest applied delta was created: yy/mm/dd
 %e%          Date newest applied delta was created: yyyy/mm/dd
 %F%          SCCS s.file name
 %G%          Date newest applied delta was created: mm/dd/yy
 %g%          Date newest applied delta was created: mm/dd/yyyy
 %H%          Current date: mm/dd/yy
 %h%          Current date: mm/dd/yyyy
 %I%          SID of the retrieved version: %R%.%L%.%B%.%S%
 %L%          SID level component
 %M%          Module name: value of the m flag or name of the s.file w/o prefix
 %P%          Fully qualified s.file name
 %Q%          Value of the q flag in the s.file
 %R%          SID Release component
 %S%          SID Sequence component
 %T%          Current time: hh:mm:ss
 %U%          Time newest applied delta was created: hh:mm:ss
 %W%          Shorthand notation for an ID line with %Z%%M%  %I%
 %Y%          Module type: value of the t flag in the s.file
 %Z%          4-character string: `@(#)'
 
 %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.

        ^A f * 

is related to %sccs.include.filename% 

A longer documentation is available with "man get". 

BTW: 64 bit versions of SCCS work until year 9999


> > Note that since 1999 every SCCS implementation is able to read 4 digit year
> > numbers correctly without a warning. Why is there a warning from your 
> > program?
>
> Because I've never seen an implementation of SCCS actually produce a
> 4-digit year.   I concluded that the SCCS file format (which, let's
> face it, isn't documented anywhere) requires 4-digit years.

"man sccsfile" will give you this documentation.

The oldest troff source file for this documentation I could find in a minute is 
from 1982. See:

        http://sccs.berlios.de/man/sccsfile.4.html

for a recent version.

> > Very strange is this:
> >
> > val: warning: s.inode.c is a BitKeeper file.
> > val: warning: s.inode.c: bad checksum (expected=52330, calculated 59498).
> > val: s.inode.c: line 51: Corrupted SCCS file. (Bad value '4' for 'e' flag.)
> >
> > If you know this is a BitKeeper file, why do you complain about the checksum
> > that you just cannot compute? Why do you complain about the value 4 for the
> > encoding flag?
>
> Maybe we should just bail on validation entirely for BitKeeper files.

I believe this is the best you can do, see:

sccs val ../s.inode.c  
    ../s.inode.c: corrupted SCCS file


> > Are you interested to follow the SCCS development with CSSC?
>
> I'm interested in maintaining compatibility.

So you will follow the planned future development?


> > There is a need to switch to GMT based time stamps in order to prevent 
> > problems
> > with deltas from the hour that you see twice while switching to DST.
>
> That's not the half of it.   The timestamps in all SCCS files are
> ambiguous for all times of day, it doesn't matter whether they specify
> a date on which some time zone has a retrograde step.   Since the file
> does not include the time zone, it is necessary (for users) to make
> some assumption about the time zone of the SCCS file.   Most people
> don't know this and it's not uncommon for the same history file to be
> updated

As long as SCCS is not network aware, it is safe to assume that all entries are 
made from the same timezone. Future network aware versions may either keep this
timezone but document it in the history file (keeping the problem at times when 
there is a DST swicth underway) or convert the file to GMT and mark it to be 
GMT based.

        BTW: this in theory could be done by a line:

        ^Ad D 1.7 11/04/30:G 16:01:50 joerg 7 6

        but it will create a warning in more recent Sun based SCCS versions.
        SCCS has a "hole" in the parser.

> > What are your future plans on CSSC?
>
> I plan to make sure it continues to work and is compatible with
> traditional SCCS implementations.

So you are not interested in recent and future enhancements?
How do you interpret "traditional"? It could be interpreted as SCCS 
implementations that are a true descendant from the original AT&T source code.


> > BTW: it seems that some of the commands from CSSC may be in conflict with 
> > SCCS.
> > If you install into /bin /usr/bin or similar, you should use different names
> > than SCCS.
>
> CSSC installs itself in the location and with program names controlled
> by the --prefix and --program-* options specified to the "configure"
> script.   That is, it goes where it's told to.   Certainly some people
> require CSSC to be able to work with their history files without any
> need for change to their shell scripts and so forth, and to do that it
> needs to use the same command names.

This looks consistent as long as you don't install a CSSC specific 
/usr/bin/sccs. 

Jörg

-- 
 EMail:address@hidden (home) Jörg Schilling D-13353 Berlin
       address@hidden                (uni)  
       address@hidden (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily