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

[James Youngman]

On Tue, May 3, 2011 at 11:12 PM, Joerg Schilling
<address@hidden> wrote:
>
> James Youngman <address@hidden> wrote:
>
>
> > > The current development version adds "^Af x SCHILY"
> >
> > Not sure if I understood you correctly here, but does this mean there
> > are no released versions of Schily-SCCS which use the "x" flag?    If
> > that is the case, can I persuade you to pick an alternative flag
> > letter which isn't already used?  Maybe something other
> > implementations are unlikely to have chosen (such as '_' or even
> > '_SCHILY')?
>
> The flag as mentioned above has been introduced in August 2008 and is in use
> since then to enable those extensions that would cause compatibility problems
> if the user is not aware of the feature in advance. This currently the 
> keywords
> %d% %e% %d% %h%

I understand why a flag is needed.    But I was asking you to consider
changing which flag letter enables these keywords so that it doesn't
conflict with the 'x' flag letter in SCO OpenServer.

> BTW: I forgot to mention that the prs command has new keywords :d: and :DY:
> for the same reason.
>
>
> > > Well, the SCO version could be seen as nearly dead I am not sure whether 
> > > there
> > > will be future development in this path.
> >
> > That's a reasonable point, but I would prefer to maintain
> > compatibility with all SCCS implementations.  So far this has been
> > possible.
>
> given the fact that the SCO sccs does not support unlimited linelength, I am
> sure I would immediately compile my SCCS and thus could make use of my history
> files that use the executable flag. I did not yet have contact with people who
> use the SCO feature, so I cannot tell how I would decide in case I receive 
> mail
> from a former SCO user.
>
> > There are exceptions to full compatibility.   One example is
> > automatically turning on the 'e' flag in "admin -i" if the input file
>
> This is done by the Solaris based source which is my source.
>
> > is binary.  The implementations lacking binary file support won't do
> > this and can't extract a correct gotten body from the encoded history
> > file, but it's fairly clear that the user is unlikely to want admin to
> > fail in this case (but if they do, there's an environment variable
> > they can set to get this
> > compatible-with-poor-implementations-but-annoying behaviour).
>
> Do you know of such implementations?

I believe Sun's SCCS implementation is the only one (besides CSSC)
which supports binary files.   That's a shame, since the feature is
very useful.

James.