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

[Joerg Schilling]

James Youngman <address@hidden> wrote:

> > the revision history for cssc. Is there something I am missing? Do you use 
> > cssc
> > for real projects?
>
> No, not any more.

Well, opengrok includes support for sccs so there is even a GUI for sccs.
Why don't you use it anymore? It still seems to be based on the most robust 
file format specification and I know nobody who did ever loss data with SCCS 
during the past 30+ years.

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

Which ones? IRIX, AIX, HP-UX and SCO document it.

> - 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? This may be a 
result of the fact that Sun destroyed the man pages while converting them to a 
Framemaker sgml plugin. It took me a long time and still takes me time to fix
the related problems.

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


> - I think there may be differences in the handling of editing
> hard-linked history files, though I have no details.

sccs is expected (from its documentation) to break hardlinks.

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

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

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

I believe I need to ignore an empty 'x' flag and probably tell people to do a 
chmod +x


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

Correct, they are needed in special as countries like the US like to use 
otherwise unusable date conventions that make it close to impossible to 
understand the 2-digit year based date notations from the current years.


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

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?

BTW: I plan to add new encodings for the content data in future. Thanks to Sun, 
for adding support for infinite length lines to the sccs commands and to 
diff(1), there are only two limitations left over for the "unencoded" format:

-       NULL bytes in the files will not work due to diff(1)

-       Files that have lines beginning with ^A

It seems to be natural to add at least a new escaped format that permits ^A at
the beginning of a line and escapes it e.g. by another ^A.

Another idea is to use the method introduced by Larry McVoy and to compress the 
file content data. 

Both new methods need to be marked in some way.


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

Do you know what this user base is?

I believe that the SCCS user base will grow once it has become network aware.

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

This is the TeamWare approach, but this only happens in big companies.


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

Architects and money will cause more harm to historic buildings than poverity.
We may have a happy situation in SCCS as nobody did try to enhance it during 
the past 30 years.

Larry McVoy first tried to stay "compatible" to SCCS but at some point 
completely gave up this idea. It may be more clean to avoid adding things that
may look compatible in the first attept but that may cause other problems.

I first thought about a "compatible" anhancement to SCCS but I now tend to add 
enhancements in a different way. The main problem with the delta table is that
SCCS does not read and kep the whole thing so it is not easy to later correct 
time stamps. Time zone corrections need to be done while one complete single 
delta entry is still available. We cannot wait until the flag area of the delta 
table was read.

11/04/30:G 16:01:50     will cause warnings

joerg:GMT               may have unknown and hard to estimate future problems

A new delta table entry like:

^AX Z GMT

is a safe way to enhance SCCS and it will cause unaware implementations to 
abort.

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

Depending on whether an implementation makes texual copies or not, an existing
implementation may even remove additional hints.

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

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

Totay, it will create:

^Ad D 1.1 ;1/04/30 21:48:07 joerg 1 0

but later reject the file as corrupted.

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

I am used to enhance archive formats in a way that will not break. 

The worst things that could happen is that a user has access to a filesystem 
carrying SCCS history files and uses an SCCS implementation that is not aware 
of the global locks I plan to introduce soon.

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

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.

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