bug-cssc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Joerg Schilling
Subject: Re: [Bug-cssc] Test delta/errorcase.sh -> E30 .. E32
Date: Sat, 21 May 2011 12:11:55 +0200
User-agent: nail 11.22 3/20/05

James Youngman <address@hidden> wrote:

> > why do you expect that it makes sense that a file with
> > no new line at the end should be "delta"d wihout error?
>
> It's a property required of CSSC but not other implementations.
> Required of CSSC because SCCS doesn't allow a history file to be
> switched to being uuencoded after its creation, and if the newline at
> EOF is deleted, we have to do something.
>
>
> > 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'm not sure why you're asking why: it's a property required of CSSC.
>  I don't hold other implementations to that.    Hence the enormous
> conditional enclosing these tests.

The test checks for something that is different from what you just explained.

It tests whether it is possible to create an encoded SCCS history file by 
calling:

        admin -b -n s.foo

As this does not match the documented behavior for SCCS, it is not expected to
succeed. 

        docommand E28 "${admin} -b -n -i/dev/null $s" 0 IGNORE IGNORE 

Will match the SCCS documentation....


The background for my mail is that there are more than 1100 tests in your suite 
and only three of them fail with SCCS:

        delta/errorcase.sh E28 (se above)
                                                This test as implemented by you
                                                does not match the documented
                                                behavior and I believe that the
                                                man page is correct here and 
                                                you should chnage your test.

        admin/r-option.sh.
        docommand t5 "${admin} -n -r2 $s" 1 "" IGNORE
                                                Here you are aligned with the
                                                documentation, but I am 
                                                interested to change the 
                                                documentation as SCCS started 
                                                to asume -n in case -i was
                                                specified and SCCS now permits
                                                -r with both -n and -i (which 
                                                looks useful).

        binary/auto.sh
        test_ascii fa11 "x\000y\n"              Is expected to succeed and not
                                                to fail as you asume, as it
                                                matches the way Sun implemented
                                                it.

I know that there are a bunch of very old SCCS versions around that will not 
pass all tests (e.g. because before Solaris, there was a line length limit of
typocally 512 bytes.

Given the fact that the current SCCS implementation can be identified by calling

        sccs -V

        Output is:
                sccs schily-SCCS version 1.00.05 2011/04/20 
(i386-pc-solaris2.11)
        or similar

it would be nice if all tests could be called and passed by both, the current 
CSSC and the current SCCS.

Conclusion:

        E28     should be changed to match the documented behavior.

        fa11    should be changed to match observed behavior from SCCS since 
                1987

        t5      We need to discuss whether it is better to match observed
                behavior from SCCS from Solaris (SVR4 behaves as documented)
                or whether it seems to be better to follow the documented
                behavior.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]