[Bug-cssc] The purpose of CSSC

[Joerg Schilling]

Hi,

what it the purpose of the CSSC implementation? Is it just for fun or is it 
intended to be valuable for dayly use?

It is intended to be fully compatible to SCCS?

Is it intended to be compatible to the POSIX standard?

This is a long list of possible problems that may need a discussion depending 
on your goals....


I just found the following oddities with "val" from CSSC:


Testing with files created by a standard UNIX SCCS, I get the following problem:

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.

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...


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).


This looks strange:

val: warning: this file has been written by a version of SCCS which uses 
four-digit years, which is contrary to the common SCCS file format (though it 
might have been a  good idea in the first place)

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?


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?


Are you interested to follow the SCCS development with CSSC?

Please note that the SCCS implementation does not check every detail in a 
history file and thus leaves room for future enhancements that will be 
accepted by every SCCS implementation but aparently not by CSSC.

BitKeeper e.g. uses a bug in the SCCS parser related to delta comments in 
order to place enhancements. I plan to implement other enhancements into SCCS 
and base them on extensions in the history file that are not flaged by SCCS.

Future SCCS implementationy may however need history file extensions that will 
not be accepted by other SCCS implementations.

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. There 
needs to be a way to mark converted SCCS history files.

What are your future plans on CSSC?


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.

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