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

[James Youngman]

On Sat, Apr 30, 2011 at 3:18 PM, Joerg Schilling
<address@hidden> wrote:
> 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?

No, not any more.


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

Another important variation is that not all vendors' implementations
support the 'b' flag.  Minor variations include
- differences in the format of the header printed by sccsdiff (both
between vendors and IIRC between Solaris 2.6 and 8).
- some implementations (ncluding Dynix) accept "admin -ifoo -n" and
reject "admin -n" alone.
- I think there may be differences in the handling of editing
hard-linked history files, though I have no details.
- some implementations don't allow a level to be specified with "admin -r".
- I believe some (quite old) implementations lack prt


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

A description of the semantics of included, excluded and ignored
deltas is clearly missing.   As are countless other things.
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.

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

Yes.   CSSC implements the x flag not because it's a good idea but
because some users may have it set in their history file and want to
interoperate with an implementation that lacks the superior "chmod +x"
support.

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

I'll take a look.

>
>> > 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: `@(#)'

So the degh flags are all simply four-digit equivalents for their
upper-case equivalents.

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

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.


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

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


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

Thanks.   Looks straightforward.

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

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.

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

s/safe/convenient/.   Plenty of teams use NFS to interoperate between
time zones.   Most of the time they get away without any adverse
effects, too.

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

We could also try putting a colon in the username to separate the real
username (which in reality cannot contain a colon, at least on systems
still using /etc/passwd) from a bunch of additional structured data.
I guess there are also other less pleasant options like keeping
metadata in the comments for a removed delta, but then even removed
deltas get printed sometimes so that would be messy.

When considering this feature, my main concern would be that we don't
do something like add a flag that older implementations ignore.  That
would mean that deltas in an unspecified timezone can be added by
those implementations, while SCCS versions that know about the flag
would assume this hadn't happened, and so would incorrectly process
the dates on the added deltas.

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


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

I guess a more specific answer is the one I gave above ("If the CSSC
user base...").   I'm not interested in making incompatible extensions
which would prejudice interoperability, certainly.

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

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.


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