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

[James Youngman]

On Sat, May 21, 2011 at 3:56 PM, Joerg Schilling
<address@hidden> wrote:
> 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.

I see.    Tests guarded by $TESTING_CSSC are tests where CSSC's
designed behaviour differs from at least one SCCS implementation.
Other SCCS implementations may coincide with CSSC.   There's also a
variable for binary file support.

So, I can see that setting $TESTING_CSSC could be interesting to you
here, because it enables additional interesting tests.   I suppose
this means that if the CSSC regression test suite is to support the
use case you're interested in (testing your implementation of SCCS
too) we will need to eliminate use of $TESTING_CSSC by changing each
example of it to a more feature-specific test.    For example,
something telling us about support for admin -b or indefinitely-long
lines.


>
>> 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 have no evidence either way, but of course this may not be true for ever.


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

If the distinction is important and not implied in the context, they
say GNU 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?

I'm not sure how illustrating potentially-confusing usage elsewhere
makes a point about SCCS implementations.

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

I'm not aware of any constraints.    I was reluctant to suggest a
specific usage out of delicacy over your preferences.   But if you
insist on hearing a suggestion, it would be this:

Schily SCCS - taken from http://sccs.berlios.de/ - refers to your
implementation.
<vendor> SCCS - refers to a SCCS implementation shipped at some point
by Unix vendor <vendor>.

Obviously there are other implementations too but they have specific
names already:
CSSC - clearly unambiguously refers to the GNU implementation I
maintain.   If this forks, I guess "GNU CSSC" is more specific.
MySC - Ross Ridge's implementation
BitSCCS - Larry's implementation
NSE, Teamware - from Sun
Sablime - from Alcatel/Lucent

Where it's material, all of these above can be qualified with a
release identifier (or Unix release in the case of <vendor> SCCS).


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

That will probably help to make it possible to replace $TESTING_CSSC
with something finer-grained.

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

I understand.  Thanks.   The conditional on $TESTING_CSSC failed to
make cleat that the "else" clause covers both some implementations
that would pass the test and some that would not.


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

Your implementation of SCCS, you mean?


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

Yes, but that version (well, actually 4.1.4, which is the earliest Sun
implementation I've actually tested) did not cover all the cases.   I
forget precisely which cases it didn't cover.

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

This is already addressed I think in my comments above about replacing
$TESTING_CSSC.

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

POSIX doesn't require it (even for diff -e with some inputs, since if
you don't need to edit the final "line" there would be no problem).

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

Obviously.   All other behaviours would generate incorrect data in the
history file.


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