Re: [Bug-cssc] Test binary/auto.sh fa11

[Joerg Schilling]

James Youngman <address@hidden> wrote:

> >> > it seems that you asume that
> >> >
> >> >        admin -ifile s.file
> >> >
> >> > does not automatically switch into binary (encoded) mode.
> >> > Is there any reason for this decision?
> >>
> >> I only assume that for non-CSSC implementations.
> >
> > I did test this with the original SCCS and it failed.
>
> That shouldn't be possible; that is the point of the conditional statement:-
>
> if $TESTING_CSSC
> then
>     ## Real SCCS fails on these inputs:-
>     test_bin   fb10 "foo"               # no newline at end of file.
>     test_ascii fa11 "x\000y\n"          # ASCII NUL.
> else
>     echo "Some tests skipped (since SCCS fails them but CSSC should pass)"
> fi
>
>
> Perhaps you set $TESTING_CSSC to true even though you were not testing
> CSSC.   If so, I would expect you to get odd test results.   Some
> tests in the test suite are not passed by all SCCS implementations.

I added SCCS to be tested also as I am interested to see whether CSSC might 
behave different from SCCS.

> You use the phrase "the original SCCS" as if there is only one.
> This is unnecessarily confusing.   Many Unix vendors have released
> SCCS implementations - albeit ultimately derived from the same code
> base - with different bugs and having or lacking different features.
>  In order to avoid needless confusion, it is necessary to be more
> specific.

I understand that it might be confusing because both is true:

-       I am talking about the original SCCS

-       There is more than one version that has been derived from
        the implementation from Marc J. Rochkind.

If you however check the other SCCS versions that have been derived from the 
original, you will find that their last development activity has been in 1999
to achieve Y2000 compliance.

I am talking about "star", when I mean the oldest OSS tar implementation I 
started to write in 1982. GNU People use the name "tar" when they are talking
about gtar (formerly known as PD-tar and SUG-tar) isn't this confusing people
much more than using the name SCCS for the only SCCS (derived from Marc J. 
Rochkind's implementation) that is still under active development?

If you have a good idea for a naming method that matches the constraintsm you
are welcome!

> > SCCS correctly detects the null byte that the test file from test fa11 
> > inserts.
>
> Only some versions of SCCS do this.   Some do not.   Therefore test
> fa11 is applied only to CSSC in order to avoid spurious failures with
> those versions of SCCS.

Current original SCCS versions contain programs that all support -V, so it is 
easy to identify them.


> > The test is then considered as failed by your script and this is why I am 
> > asking.
>
> Test fa11 is applied only to CSSC.   It verifies that files lacking a
> final newline are treated as binary files by CSSC.   If this test
> fails on CSSC, then this is a bug in CSSC.  I will fix it.   Is this
> what you experienced?

As I mentioned, I did run the test with SCCS and I see a test that does not 
match the behavior of SCCS. You told me that you are interested to match SCCS 
behavior in your CSSC implementation, this is why I reported the problem.

> If you saw something different, you're applying a test intended only
> for CSSC to something else, and perhaps it will pass, perhaps not -
> this is going to depend on the properties of the specific SCCS
> implementation.   In the end the propoerties of the diff command being
> used will also be relevant to whether a file lacking a final newline
> can really be correctly dealt with by a non-encoded SCCS history file.
>   In fact as far as POSIX is concerned text files must end in a
> newline (since it says they're composed of lines, all of which must
> end in newline).

Regardless of what POSIX says, the SCCS weave delta format does not allow to 
deal with unencoded data that does not end in a new line.

A test similar to what you coded makes sense - I just would like to see a test 
that matches the behavior of SCCS.

> > BTW: I verified that SunOS-3.5 does not support encoded files, so this 
> > seems to
> > be a feature from SunOS-4 (most likely as a result of the efforts for NSE 
> > that
> > contained the first project oriented SCM [based on SCCS] and that came up to
> > the end of the SunOS-3.5 period shortly before SunOS-4.0 came out).
> >
> > So the question is:
> >
> > fa11 fails with the original SCCS, does it fail with CSSC too?
>
> No.   When the test was introduced in February 1998, it originally
> verified that CSSC followed the then behaviour of SCCS, but I updated
> it the following month to allow CSSC to succeed.

The behavior of SCCS did not change since then. Even the SCCS from SunOS-4.0
(1987) did run an automatic check on whether the file needs binary encoding.


> > It is intended that this test should fail?
>
> No.  That's why it's included in the regression test suite.

Would you then be interested to make it be aligned with the SCCS behavior?


> > BTW: When I should discuss the behavior of SCCS, I would like to be able to
> > tell SCCS not to automatically switch to binary mode (e.g. via an 
> > environment
> > varibale to catch the case where the only reason for bein "binary" is a 
> > missing
> > new-line character at the end of the file.
>
> This strategy would certainly least surprise the user.  That would of
> course be a good thing.   But it does mean that correct operation then
> relies on the ability of the user's diff command (whichever is first
> on $PATH) to work with files lacking a terminating newline.   Of

The UNIX diff program calls exit(1) if one of the files does not end in a 
newline. 

Before December 2006, there has been no portable SCCS implementation but 
several variants that relied on the respective diff(1) found on /usr/bin.
This is why SCCS comes with a portable variant of the UNIX diff program
in $(INS_DIR)/ccs/bin/ since January 2007 and why SCCS calls this included diff 
in order to e.g. be able to support "unlimited" line lengths.

> course, it is always possible for a user to admin -i with a text file
> having a final newline, and then remove the terminating newline.   So
> in principle we can always have this problem.

If you do this, SCCS will get an exit code of 1 from diff and complains instead 
of introducing a new delta.

> CSSC allows the user to make this choice to override the default by
> setting CSSC_BINARY_SUPPORT=disabled when they run admin.

SCCS does not allow to change a history file from unencoded to encoded if there 
is content already. I was thinking about an environmental variable that could
prevent SCCS from automatically assuming binary mode just because the final 
new line is missing in a text file.

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