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

[James Youngman]

On Tue, May 3, 2011 at 3:11 PM, Joerg Schilling
<address@hidden> wrote:
> James Youngman <address@hidden> wrote:
>
>> > 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.
>> >
>> > It seems however that I should ignore the 'x' flag in case that it has not 
>> > been
>> > added together with the "SCHILY" argument.
>>
>> Or you could support the SCO semantics if the flag value is "1" rather
>> than "SCHILY".   Up to you.
>
> It may be a better solution to write a warning hint to chmod +x
>
>
>> However, there's still an incompatibility.  The problem is, what an
>> implementation should do in response to:
>>
>> admin -fx /somepath/s.foo
>>
>> Clearly there are two options:
>>
>> 1. Set the x flag to 1: be compatible with SCO SCCS
>> 2. Set the x flag to SCHILY: be compatible with Schily SCCS v 1.1 and
>> later (I think that's the right version)
>
> 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')?

>> I can't see a way for the admin program to determine which behaviour
>> the user wants.   Apart of course from introducing an incompatible
>> configure-time selection or relying on some environment variable.   I
>> don't think using stat on the g-file is likely to be reliable enough,
>> especially since there may be no gfile.
>
> 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.

There are exceptions to full compatibility.   One example is
automatically turning on the 'e' flag in "admin -i" if the input file
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).

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