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

[Joerg Schilling]

James Youngman <address@hidden> wrote:

> > The current development version adds "^Af x SCHILY"
>
> Not sure if I understood you correctly here, but does this mean there
> are no released versions of Schily-SCCS which use the "x" flag?    If
> that is the case, can I persuade you to pick an alternative flag
> letter which isn't already used?  Maybe something other
> implementations are unlikely to have chosen (such as '_' or even
> '_SCHILY')?

I am not sure what you understand by "released", but there have been 27 SCCS 
releases since the 'x' flag has been introduced the way it is currently used.

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

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

A general problem is that Larry McVoy did already add a lot of flags to older 
BK SCCS implementations that still use the magic ^Ahddddd and thus are expected 
to be "compatible" to SCCS.

See for his documentation:

p       Bit     specifies the path of the file.  There will be multiple of these
                if the path name changes.  The format is <rev> <path>
h       Bit     specifies the host name on which the file was created/modified.
                There will be multiple of these if the file is checked in on
                different hosts. The format is <rev> <host>
w       Bit     specifies the minuteswest of GMT.  There will be multiple of
                these if the file is checked in in different time zones.
                The format is <rev> <hh:mm>
s       Bit     specifies a rev symbol pair.  Simulates RCS symbolic names.
                The format is <rev> <symbol>, and there can be multiple of
                these.
S       Bit     specifies the state of of a revision or branch.  Simulates
                RCS state flags.  The format is <rev> <state> and there can
                be multiple of these.
R       Bit     specifies that RCS flags should be expanded.

Y       Bit     specifies that years should be expanded as 4 digits.

There is also the undocumented '&' flag in BK-0.5.2.

As you can see, Larry did eat up nearly all free characters. He also planned 
more:

a
g
h       hostname
k
o
p       pathname
r       line of development (LOD) symbols
s       symbol
u
w       minutes west of GMT time
x       bitmap          1 == RCSFLAG, 2 == year as 4 digits
y       state
z       landing pad

As you see, even though Larry did work at Sun untill ~ 1993, he  did not check 
what Sun did later and he is in conflict with the flags 'y' and 's' used by Sun.
This causes e.g. Sun's SCCS not to expand any keyword in case you try to "get"
on any of the SCCS history files that have been supplied with BK SCCS 0.5.2.
Larry is also in conflict with the 'x' flag with the current SCCS development 
line (mine) and with the SCO variant.



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

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

BTW: BK uses the following encoings:

        0       no encoding, then "weaved"
        1       UUencoded, then "weaved"
        2       gzip'ed. then UUencoded, then "weaved"
        3       ??? is this used or just skipped ???
        4       "weaved", then gzip'ed
        5       "weaved", then some other compressed encoding used e.g. for
                GIFs that I could not yet decode.

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.

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

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