James Youngman <j...@gnu.org> wrote: > On Tue, Jun 14, 2016 at 11:29 AM Joerg Schilling > <joerg.schill...@fokus.fraunhofer.de> wrote: > > CSSC even refuses the "s" flag that has been introduced by Sun ~ 30 years > > ago and writes a message: Corrupted SCCS file. (Unknown flag 's'.) instead > > of > > getting a version. The s flag is important if you need some printf() format > > strings in the code that have a clash with get keywords, but still have an > > expanded version string at the top of a file. > > This is true; CSSC doesn't understand this flag. This is likely > because nobody reported this as a bug to me, so I was unaware of the > existence of the flag on some versions of Unix.
I am not sure, but I believe that the SCCS man pages have been available in the net for a while - well most likely not before you reduced your effort on CSSC. The "s" flag appeared in early 1986 on SunOS, when Sun introduced NSE - the "Network Software Environment" - the first distributed source code control system and it is part of the maintained official SCCS source. > If you would be so kind as to describe specifically the behaviour of > the flag, I'd be happy to implement it. Check the SCCS project at: http://sccs.sourceforge.net/ and look at the man pages, e.g.: http://sccs.sourceforge.net/man/sccs-admin.1.html The "s" flag is on page 4. It is easy to implement and quite helpful in special since new lower case keywords for 4-digit years numbers have been introduced in 2008. These keywords interfere with printf() formats and may cause problems if the keyword expansioon is not limited to a special number of lines. BTW: there is a general problem with CSSC that is related to the fact that CSSC checks things that SCCS intentionally does not check. The file format at a specific level intentionally allows future enhancements. CSSC however checks things it should not check: - The historical SCCS may core dump if you add upper case flags, but is intentionally does not check for unknown lower case flags and handles them in an agnostic method: it forwards text for unknown flags to new versions without modifying the text. - The historical SCCS intentionally does not check what is between the flags section and the comment file section. It rather forwards anything unmodified that is between the last "^Af" line and the "^At" line when creating new history file versions. - The historical SCCS does not check for a space after a "^Ac" delta comment and both BitKeeper SCCS and the recent version of the original SCCS use degenerated "^Ac_XXX" delta comments to keep extended information. SCCS e.g. uses these comments to keep nanoseconds and the timezone from SCCS V6 history files that have been converted back into the SCCS V4 format. CSSC should at least permit and keep "^Ac_" followed by anything. - The historical SCCS did document a maximum serial number of 30000 for SCCS history files but never verified this. The original SCCS thus is able to have at least 2 billion versions inside a SCCS history file and I already created a SCCS history file with 3 million deltas. CSSC should not artificially introduce such limits if it looks for users. See the man page: http://sccs.sourceforge.net/man/sccsfile.4.html for a documentation of the current SCCS format. As documented in this man page, SCCS needs 300 MB of virtual memory in order to unpack a history file with 3 million deltas. Please note that I negotiated a OSS SCCS with SCO in 2001, but this was not implemented because a few weeks before the source should be handed over, a Linux company called "Caldera" bought SCO and had no interest in OSS.... I later negotiated with Sun to make SCCS opensource and finally succeeded in December 2006. So the original SCCS code is now available as OSS and it is actively maintained since then. SCCS is still the fastest source control system available and it is available as legal OpenSource to the public since 12.5 years now. Jörg -- EMail:jo...@schily.net (home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
