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

[James Youngman]

On Thu, May 5, 2011 at 12:07 PM, Joerg Schilling
<address@hidden> wrote:
> Also note that SCCS is expected to dump core in case you let it read a history
> file that contains a flag from outside the range 'a'..'z'.

Expected?   I'm sure nobody has ever stated dumping core as a requirement.

> Introducing _new_
> flags from outside the range 'a'..'z' thus only makes sense if the history
> format is made incompatible in a way that causes historic versions of SCCS to
> abort with:

One could argue that this is better.   Exiting with a zero status
while not producing the data in the g-file that the user wanted (e.g.
not expanding the extended keywords) violates the principle of least
surprise.


> get s.xx9
> ERROR [s.xx9]: format error at line 4 (co4)
>
> sccs help co4
> co4:
> "format error at line ..."
> The format of the SCCS file is logically invalid.  The error
> was discovered at the stated line.  See if you can find
> the problem with the prs command.  If not, do a "help stuck".
>
> /opt/schily/ccs/bin/val -T s.xx9
>    s.xx9: invalid delta table at line 4
>    s.xx9: corrupted SCCS file
>
> ^Ah41801
> ^As 00001/00001/00013
> ^Ad D 1.2 07/01/27 15:05:05 joerg 2 1
> ^AS test
> ^Ac man neu
> ^Ae

Not really sure what point you're making here.   Flag settings are
introduced with ^Af.

>> > 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.
>
> Sun did already work on a lot of buffer overflow problems in SCCS and I did 
> fix
> a lot of other such problems. I expect that the SCO source has no such fixes
> and that it is better to upgrade to more recent SCCS versions than to continue
> to use the SCO variant.

It's probably more an issue for checking out historic source files.

>> 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).
>
> Are you sure? I believe before this was implemented, you could create an empty
> history file, manually turn on uuencoding and then enter binary content.

I've checked a number (2 or so) of non-Sun implementations for "admin
-fe" and didn't find one that supported it.   But there are a number
of implementations that have local differences that I have been unable
to try out myself (for example Data General Unix).

> I have no idea how the checksum is computed in cases 4 & 5. It cannot be the
> standard SCCS algotithm on the plain s. file starting with line 2.

I don't know either.   But a better checksum algorithm wouldn't be
such a bad plan.  The historic one is very weak.   Fortunately typical
source repositories are also very small.

> Compression is a really interesting feature as it typically allows to reduce
> the size of a history file to less than the size of the g-file. Compreession 
> is
> needed in order to be competitive with mercurial (e.g. for a "clone" over the
> network).

Overall file size is certainly a useful axis along which to optimise.
 But there are other important ones, for example the relationship
between the runtime and the total number of deltas (even non-ancestor
deltas).   For SCCS this is linear, but a redesigned file format could
reduce it.

James.