Re: [Bug-cssc] Test delta/errorcase.sh -> E30 .. E32

[James Youngman]

On Fri, May 20, 2011 at 6:13 PM, Joerg Schilling
<address@hidden> wrote:
> address@hidden (Joerg Schilling) wrote:
>
>> Hi,
>>
>> why do you expect that it makes sense that a file with
>> no new line at the end should be "delta"d wihout error?
>>
>> Why do you expect that it is possible to retrieve back such
>> a file and successfully compare it with the original file that
>> misses the newline at the end?
>
> I just found that you seem to assume that
>
>        admin -b -n s.foo
>
> will create an amty history file suitable for encoded files.
>
> It seems that the binary encoding flag has been introduced by Sun somewhere in
> the 1980s (it is supported on SunOS-4.1). On SunOS-4.1, you however will get 
> an
> error message:
>
> /usr/sccs/admin -n -b s.foo
> ERROR: 'b' keyletter can only be used with 'i' keyletter (ad33)
>
> sccs help ad33
>
> ad33:
> "'b' keyletter can only be used with 'i' keyletter"
> The -b option, which indicates that a
> file should be treated as binary and
> checked in in an encoded form, may only>
>
>  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
>
> _______________________________________________
> bug-CSSC mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/bug-cssc
>

> be specified if an SCCS file is being
> initialized.

A rather odd explanation for this message; clearly, an SCCS file
actually is being initialised.

> SCCS on Solaris automatically assumes -n if you specify -i and it seems that
> the warning above has been removed for unknown reason, but the encoding flag
> is only added in case that you use -i.
>
> We should discuss which behavior should be expected here......

I haven't had access to a 4.1 system for testing since around 1998.
 In cases where SCCS implementations differ I normally select the
behaviour that I think is most likely to reflect what the user expects
(a notable exception here is where the user has essentially requested
that this not happen, e.g. by setting $CSSC_MAX_LINE_LENGTH.

The intent of the command "admin -n -b s.foo" is pretty clear, so I
guess I simply implemented the user's likely intent.   As do later
releases of SCCS.

James.