Nabble - Gnu - CSSC - Users

Re: does keyword expansion work?

2009-09-10T13:29:39Z

Alright, I'll have to chalk it up as some sort of
operator error somewhere--since I did not keep a log to show.

It worked just fine this morning. Sorry for the alarm.
Thanks for the help.

--
On 09/10/2009 02:03 AM, James Youngman wrote:

> On Thu, Sep 10, 2009 at 1:31 AM, Christopher Chen
> <christopher.chen@...> wrote:
>> Hi,
>>
>> I'm using CSSC-1.2.0. The keyword expansion feature (ex. %W%) does
>> not seem to be working. Does it work?
>
> It does:
>
> $ rm -f s.foo foo; echo "Hello. %W%." > foo ; ./admin -i s.foo < foo
> ; ./get -p s.foo 2>/dev/null; rm -f s.foo foo
> Hello. @(#)foo 1.1.
> $ rm -f s.foo foo; echo "Hello. %W%." > foo ; ./admin -i s.foo < foo
> ; ./get -wBLAH -p s.foo 2>/dev/null; rm -f s.foo foo
> Hello. BLAH.
>
> James.

_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

Re: does keyword expansion work?

2009-09-10T02:03:39Z

On Thu, Sep 10, 2009 at 1:31 AM, Christopher Chen
<christopher.chen@...> wrote:
> Hi,
>
> I'm using CSSC-1.2.0. The keyword expansion feature (ex. %W%) does
> not seem to be working. Does it work?

It does:

$ rm -f s.foo foo; echo "Hello. %W%." > foo ; ./admin -i s.foo < foo
; ./get -p s.foo 2>/dev/null; rm -f s.foo foo
Hello. @(#)foo 1.1.
$ rm -f s.foo foo; echo "Hello. %W%." > foo ; ./admin -i s.foo < foo
; ./get -wBLAH -p s.foo 2>/dev/null; rm -f s.foo foo
Hello. BLAH.

James.

_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

Re: does keyword expansion work?

2009-09-09T17:44:40Z

On Wed, Sep 09, 2009 at 05:31:39PM -0700, Christopher Chen wrote:
> I'm using CSSC-1.2.0. The keyword expansion feature (ex. %W%) does
> not seem to be working. Does it work?

It works in BitKeeper just fine :) Not that that helps you much, but
at least you know there is a (commercial) option that works...

We support many of the RCS keywords too, but not $Log$, I always thought
that was a bit over the top. Here's our list if you care.

--lm

bk keywords(2009-08-20) BitKeeper User's Manual bk keywords(2009-08-20)

NAME
bk keywords - list of RCS and SCCS keywords

DESCRIPTION
BitKeeper supports both the standard SCCS keywords, as well as most of
the RCS keywords. In addition, there are several keywords that are
unique to BitKeeper.

Note: All of the revision-oriented keywords (e.g. %I%) are useless in
BitKeeper since they may change as a result of a re-synchronization
that causes a branch creation. Use the %K% keyword when you need an
identifier that is unique to a specific revision-level of a file. The
%K% keyword is useful when tracking customer bugs. For example, a tech-
nician might ask the end-user to run the what command on an executable
to check the versions of the components that make up a program. The
person doing troubleshooting can then use the %K% keyword to track down
the specific source files that make up the executable.

Note: SCCS keyword expansion can cause problems in printf-like strings.
To deal with unwanted keyword expansion, BitKeeper can be given options
to expand only the first keyword found. See bk help admin.

SCCS KEYWORDS
%A% Shorthand notation for an ID line with data for what(1):
%Z% %M% %I%%Z% @(#) GET 1.1@(#)
%B% SID branch component 0
%D% Current date: yyyy/mm/dd 1991/04/13
%E% Date newest applied delta was created: 1991/04/13
%F% SCCS s.file name SCCS/s.GET
%G% Date newest applied delta was created: mm/dd/yyyy 4/13/1991
%H% Current date: mm/dd/yyyy 4/13/1991
%I% SID of the retrieved version: %R%.%L%.%B%.%S%
1.1 or 1.1.0.0 if fully specified as shown in the previous line
%K% Key for the delta (these do not change)
lm@...|src/bkhelp.txt|19991116191217|50766
%L% SID level component 1
%M% Module name: either the value of the m flag in the s.file
or the name of the s.file less the prefix
%P% Fully-qualified s.file name /u/lm/SCCS/s.GET
%R% SID Release component 1
%S% SID Sequence component 0
%T% Current time: hh:mm:ss 12:41:29
%U% Time the newest applied delta was created: hh:mm:ss 12:41:29
%W% Shorthand notation for an ID line with data for what:
%Z%%M% %I% @(#)GET 1.1
%Y% SCCS Compatible, not expanded in BitKeeper
%Z% 4-character string: recognized by what. @(#)
%@% user@host
%#% user

RCS KEYWORDS
The following is the subset of RCS keywords that BitKeeper supports.
The RCS keywords are only expanded if the RCS flag is turned on. See
bk help admin.

$Revision$ $Revision: 1.2 $
$Id$ $Id: s.rcs_expand.c 1.2 99/11/16 11:25:18-08:00 lm@... $
$Author$ $Author: lm@... $
$Date$ $Date: 99/11/16 11:25:18-08:00 $
$Header$ $Header: SCCS/s.rcs_expand.c 1.2 99/11/16 11:25:18-08:00 lm@... $
$RCSfile$ $RCSfile: s.rcs_expand.c $
$Source$ $Source: /tmp/beta11/src/SCCS/s.rcs_expand.c $

SEE ALSO
bk help admin, bk help config-etc, bk help co

CATEGORY
Overview

BitMover, Inc bk keywords(2009-08-20)
--
---
Larry McVoy lm at bitmover.com http://www.bitkeeper.com

_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

does keyword expansion work?

2009-09-09T17:31:39Z

Hi,

I'm using CSSC-1.2.0. The keyword expansion feature (ex. %W%) does
not seem to be working. Does it work?

Thx.

Chris C.

_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

Would you like to help maintain CSSC?

2009-07-11T08:34:08Z

I still make occasional releases of CSSC but the reality is that I
also have other commitments (notably findutils) and I'm putting less
energy into CSSC these days. This is also partly because I no longer
use SCCS source archives in my day job any more (this is something of
an excuse since I stopped actually doing that in 1998).

An illustrative example is that a simple feature request ("get -l") is
left pending because I have not been able to find the time to work on
it.

So, I'm looking for someone able to take on some of the responsibility
for the maintenance and future direction of the package. Please let
me know if you are interested.

(Some possible volunteers are BCC'ed on this email.)

James.

_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

Re: prs "issue", etc

2009-04-15T05:55:41Z

Yes, the sccs commands (admin, delta, get, prs, etc.) were in /usr/bin on
real UNIX systems, which explains why they are all in section 1 of my
ancient "Release 5.0 Bell Laboratories UNIX operating system user's
manual".

I've long been annoyed that CSSC installs the commands elsewhere than
/usr/bin. The symlinks would work around the non-standard /usr/lib/cssc
location, but it seems inelegant. I suppose installing the commands in
/usr/bin and doing ln -s /usr/bin /usr/lib/cssc would be more standard and
provide backward compatibility.

--
Eric Krohn

_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

Re: prs "issue", etc

2009-04-14T20:49:39Z

James,

I have had hardly any experience with using the SCCS commands on the command line. Our company has been "protected" from dealing with these by our own in-house highly- customised "sccs" script, which I think dates back to the early 1990s. So the information I can glean might be a bit superficial.

> The manpage I am looking at says:

> -l Requests information for all deltas created later than, and

> including, the delta indicated with -r or -c.

> ... but you didn't specify -c or -r. Do you have any documentation

> from a vendor indicating in more detail what the intended behaviour is

> for this case?

My documentation says the same, and no I didn't specify the "-r" or "-c". Being Solaris, the man pages are "a bit light", shall we say.

I did some checking and found that we have only one script that uses "prs -l", and this usage started in Feb 2001 when we moved from using "prs -d" on DG-UX to "prs -l" on an HP-UX server.

Looks like our usage of the "-d" option was equally "fast and loose" as we didn't provide any data keywords which are supposed to be required according to current man pages on AIX and Solaris.

According to AIX's man pages, we could have used "prs -l -r" without a SID to get the same effect, but "prs -l <s.filename>" has worked for us on HP-UX, AIX and Solaris. Both seem to work the same on AIX and Solaris.

Another case of undocumented features, I presume.

> In your test file, all the null deltas were created at 09/04/15

> 11:05:36. So all the deltas down to 3.1 have the same timestamp.

> You're getting all the deltas created at the same time as the most

> recent one. However, this is not necessarily the same as "all deltas

> created later than, and including", since the order of SID creation

> can normally be disambiguated by position in the delta table or

> sequence number.

I'm not sure, but I think this is always the case - the auto null (intermediate) deltas are created when the new version is put back in (delta -mmr-list).

I tried using "prs -l -r 24.1" from CSSC but that doesn't work either - all the auto null deltas are listed. It seems to work okay with Solaris and AIX (native prs), i.e. only deltas 24.1, 25.1 and 26.1 are displayed.

> Looking at the POSIX standard, the behaviour of the operating systems

> you listed does seem to be conforming, and the behaviour of CSSC here

> does seem to be somewhat on the doubtful side, though I'm not certain

> it is definitively not conforming.

> All things considered, I believe a code change is probably indicated.

> However, I also note that the test suite coverage for prs is quite

> poor. The -l option in particular is not covered. Could you supply

> a patch adding some relevant test cases in order to make sure that the

> change we make doesn't break something else, but does fix this

> problem?

I will give it a go.

> > 2. I've just noticed that the CSSC "commands" call be run as standalone

> > programs.

> Likewise SCCS.

> > Is there a configure switch that will install get, admin, delta,

> > etc in /usr/bin instead of /usr/libexec/cssc?

> This should work, but I have not tried installing it that way in a

> long time. Looking at the top-level Makefile.am, I see that it will

> probably always use $(libexecdir)/cssc and so at least part of the

> install directory is not under your control. You could have a go

> with --execprefix (start with "configure --help") but I suspect that

> that won't do what you want (or it will break sccsdiff). I'd suggest

> that your best strategy is probably to use symbolic links.

> > I guess I could just add that directory to the PATH.

> The only Unix system I can recall where the SCCS tools are on the

> default PATH is HP-UX (at least, older versions). Solaris puts them

> in /usr/ccs/bin. I forget where AIX puts them.

The "default PATH" is of course configurable on Solaris in /etc/default/login, in /etc/environment on AIX, and /etc/PATH under HP-UX. There is a /usr/ccs/bin directory on HP-UX 11.00, but the SCCS commands are in /usr/bin. The SCCS commands for AIX are also in /usr/bin. There are also some more-POSIX-conforming versions of get and delta in /usr/xpg4/bin on Solaris 9+ (I think).

When setting up a new server, I usually change the default PATH because it is not much use for our company, but I suppose the supplier's intention is to start with a "safe" minimalist environment.

Geoff

_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

Re: prs "issue", etc

2009-04-14T17:41:12Z

On Wed, Apr 15, 2009 at 12:28 AM, Geoff Hull <gbh@...> wrote:
> Hi.
> 1. The main "issue" we have since switching to CSSC is the output when we do
> a "prs -l" on a file with Auto Null Deltas. (All our files have this
> switched on.) I have attached an example file. I have downloaded CSSC
> version 1.2.0 and compiled it, just to be sure that the problem was still
> there.
> On Solaris (and AIX and HP-UX) this is all I get:
> /home/gbh$ prs -l s.mytest

The manpage I am looking at says:

-l Requests information for all deltas created later than, and
including, the delta indicated with -r or -c.

... but you didn't specify -c or -r. Do you have any documentation
from a vendor indicating in more detail what the intended behaviour is
for this case?

In your test file, all the null deltas were created at 09/04/15
11:05:36. So all the deltas down to 3.1 have the same timestamp.
You're getting all the deltas created at the same time as the most
recent one. However, this is not necessarily the same as "all deltas
created later than, and including", since the order of SID creation
can normally be disambiguated by position in the delta table or
sequence number.

Looking at the POSIX standard, the behaviour of the operating systems
you listed does seem to be conforming, and the behaviour of CSSC here
does seem to be somewhat on the doubtful side, though I'm not certain
it is definitively not conforming.

All things considered, I believe a code change is probably indicated.
However, I also note that the test suite coverage for prs is quite
poor. The -l option in particular is not covered. Could you supply
a patch adding some relevant test cases in order to make sure that the
change we make doesn't break something else, but does fix this
problem?

> s.mytest:
> D 26.1 09/04/15 11:05:36 gbh 28 27 00020/00000/00009
> MRs:
> 7755
> COMMENTS:
> lots more text
> But with CSSC, I get all the deltas from 26.1 back to 3.1

> 2. I've just noticed that the CSSC "commands" call be run as standalone
> programs.

Likewise SCCS.

> Is there a configure switch that will install get, admin, delta,
> etc in /usr/bin instead of /usr/libexec/cssc?

This should work, but I have not tried installing it that way in a
long time. Looking at the top-level Makefile.am, I see that it will
probably always use $(libexecdir)/cssc and so at least part of the
install directory is not under your control. You could have a go
with --execprefix (start with "configure --help") but I suspect that
that won't do what you want (or it will break sccsdiff). I'd suggest
that your best strategy is probably to use symbolic links.

> I guess I could just add that directory to the PATH.

The only Unix system I can recall where the SCCS tools are on the
default PATH is HP-UX (at least, older versions). Solaris puts them
in /usr/ccs/bin. I forget where AIX puts them.

James.

_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

prs "issue", etc

2009-04-14T16:28:09Z

Hi.

1. The main "issue" we have since switching to CSSC is the output when we do a "prs -l" on a file with Auto Null Deltas. (All our files have this switched on.) I have attached an example file. I have downloaded CSSC version 1.2.0 and compiled it, just to be sure that the problem was still there.

On Solaris (and AIX and HP-UX) this is all I get:

/home/gbh$ prs -l s.mytest

s.mytest:

D 26.1 09/04/15 11:05:36 gbh 28 27 00020/00000/00009

MRs:

7755

COMMENTS:

lots more text

But with CSSC, I get all the deltas from 26.1 back to 3.1

2. I've just noticed that the CSSC "commands" call be run as standalone programs. Is there a configure switch that will install get, admin, delta, etc in /usr/bin instead of /usr/libexec/cssc? I guess I could just add that directory to the PATH.

Regards,

Geoff

_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

s.mytest (5K) Download Attachment

GNU CSSC 1.2.0 is released

2009-04-11T12:06:39Z

I'm pleased to announce the release of GNU CSSC, version
1.2.0.

This is a stable release and follows the previous stable release
1.0.1. Stable releases of CSSC are available from ftp.gnu.org.

CSSC ("Compatibly Stupid Source Control") is the GNU
project's replacement for the traditional Unix SCCS suite.
It aims for full compatibility, including precise nuances of
behaviour, support for all command-line options, and in most
cases bug-for-bug compatibility. CSSC comes with an
extensive automated test suite.

If you are currently using SCCS to do version control of
software, you should be able to just drop in CSSC, even for
example if you have a large number of shell scripts which
are layered on top of SCCS and depend on it. This should
allow you to develop on and for the GNU/Linux platform if
your source code exists only in an SCCS repository. CSSC
also allows you to migrate to a more modern version control
system (such as CVS or git).

There is a mailing list for users of the CSSC suite. To
join it, please send email to <cssc-users-request@...>
or visit the URL
http://lists.gnu.org/mailman/listinfo/cssc-users.

For more information about CSSC, please see
http://www.gnu.org/software/cssc/.

In the file docs/CREDITS within the CSSC distribution, there
is a full list of people who have contributed to the
development of CSSC. They are listed briefly here :-

James Youngman, Ross Ridge, Eric Allman, Lars Hecking,
Larry McVoy, Dave Bodenstab, Malcolm Boff, Richard Polton,
Fila Kolodny, Peter Kjellerstedt, John Interrante,
Marko Rauhamaa, Achim Hoffann, Dick Streefland,
Greg A. Woods, Aron Griffis, Michael Sterrett,
William W. Austin, Hyman Rosen, Mark Reynolds,
Sergey Ostashenko, Frank van Maarseveen, Jeff Sheinberg,
Thomas Duffy, Yann Dirson

Many thanks to all the above people.

Changes since the previous stable release are:

New in CSSC-1.2.0, 2009-04-11

    * This stable release is almost identical to the 1.1.1 test
          release; there are no functional changes.

New in CSSC-1.1.1, 2008-01-18

    * Updated the NEWS file to give estimated release dates
    and user-visible changes for ancient releases.

    * The -l and -L options of "get" are now implemented.

    * If you use "admin -dlX" to unlock release X, but all
    releases are locked, an explanatory error message is issued.
    Previously, the attempt was simply silently ignored.

    * prs no longer has a -R option.

    * When CSSC tools are passed the name of a directory on the
    command line, they operate on the SCCS files in that directory.
    As of this release, subdirectories are ignored (instead of
    generating an error when CSSC tries to open the directory as
    a file).

New in CSSC-1.1.0, 2007-12-17

    * GNU CSSC is now distributed under version 3 of the GNU General
    Public License. The documentation is distributed under
          version 1.2 of the GNU Free Documentation License.

    * We now require the C++ compiler to support exceptions in
          order to compile successfully. Previously, CSSC allowed
          compilation without exceptions, but this meant that graceful
    recovery from failures was not possible.

    * Fixed a spurious failure when writing out the SCCS file when
          the Y flag is set in the SCCS file.

    * "sccs unedit /tmp/SCCS/s.foo" will no longer cause the
    deletion of ./s.foo, if it exists. Instead, ./foo will be
          deleted, as intended.

    * Support for some older SCCS files as produced by Unix System III
    (some of these have leading spaces in the counts of inserted/
    deleted/unchanged lines in the delta table).

    * Compilation fixes for Darwin

Checksums for the release file are:
md5 1110fc2fbc009c1b6ee5306b7baa8fa6 CSSC-1.2.0.tar.gz
sha1 45a7130e49b7abaffc2a784c7a0cddf39d0af844 CSSC-1.2.0.tar.gz

_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

Re: CSSC 1.1.1 is released

2008-01-21T01:48:04Z

On Jan 18, 2008 10:21 AM, James Youngman <jay@...> wrote:
> I'm pleased to announce the release of GNU CSSC, version
> 1.1.1.
>
> This is a test release and so it is available from
> ftp://alpha.gnu.org/gnu/cssc.

There was a certain amount of delay in the automated processing of the
upload, but the file is indeed now available from alpha.gnu.org.
Please let me know how you get on with the new release.

James.

_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

CSSC 1.1.1 is released

2008-01-18T02:21:30Z

I'm pleased to announce the release of GNU CSSC, version
1.1.1.

This is a test release and so it is available from
ftp://alpha.gnu.org/gnu/cssc.

The most recent stable release is 1.0.1; that release is available
from ftp.gnu.org.

CSSC ("Compatibly Stupid Source Control") is the GNU
project's replacement for the traditional Unix SCCS suite.
It aims for full compatibility, including precise nuances of
behaviour, support for all command-line options, and in most
cases bug-for-bug compatibility. CSSC comes with an
extensive automated test suite.

If you are currently using SCCS to do version control of
software, you should be able to just drop in CSSC, even for
example if you have a large number of shell scripts which
are layered on top of SCCS and depend on it. This should
allow you to develop on and for the GNU/Linux platform if
your source code exists only in an SCCS repository. CSSC
also allows you to migrate to a more modern version control
system (such as CVS, perhaps).

There is a mailing list for users of the CSSC suite. To
join it, please send email to <cssc-users-request@...>
or visit the URL
http://lists.gnu.org/mailman/listinfo/cssc-users.

For more information about CSSC, please see
http://www.gnu.org/software/cssc/.

In the file docs/CREDITS within the CSSC distribution, there
is a full list of people who have contributed to the
development of CSSC. They are listed briefly here :-

James Youngman, Ross Ridge, Eric Allman, Lars Hecking,
Larry McVoy, Dave Bodenstab, Malcolm Boff, Richard Polton,
Fila Kolodny, Peter Kjellerstedt, John Interrante,
Marko Rauhamaa, Achim Hoffann, Dick Streefland,
Greg A. Woods, Aron Griffis, Michael Sterrett,
William W. Austin, Hyman Rosen, Mark Reynolds,
Sergey Ostashenko, Frank van Maarseveen, Jeff Sheinberg,
Thomas Duffy, Yann Dirson

Many thanks to all the above people.
New in CSSC-1.1.1, 2008-01-18

* Updated the NEWS file to give estimated release dates
and user-visible changes for ancient releases.

* The -l and -L options of "get" are now implemented.

* If you use "admin -dlX" to unlock release X, but all
releases are locked, an explanatory error message is issued.
Previously, the attempt was simply silently ignored.

* prs no longer has a -R option.

* When CSSC tools are passed the name of a directory on the
command line, they operate on the SCCS files in that directory.
As of this release, subdirectories are ignored (instead of
generating an error when CSSC tries to open the directory as
a file).

Please report any bugs via this software to the CSSC bug reporting
page, http://savannah.gnu.org/bugs/?group=findutils

_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

Re: Implementing "get -l" (was: Re: CSSC)

2008-01-07T14:54:50Z

On Jan 7, 2008 5:12 PM, Klaus Metzger <klaus.metzger@...> wrote:

> Hello James,
>
> enclosed answers to your question 1 to 4 and 6,7 and the additional from
> your next email
>
> A. The command
> >get -l SCCS/s.P26J000001.input
> delivers the l.P26J000001.input
>
> B. The command
> >get -l SCCS/s.P26J000001.input

As far as I can determine, this command is identical to the previous
one, is that what you planned? Or did you mean "-lp"?

> which Im mostly using, does not create the l file, it just prints the
> result on the screen
>
> storm_KPM> get -lp SCCS/s.P26J000001.input
> the message on the screen is
> then--------------------------------------------
> 1.7
> 1.7 08/01/07 07:58:35 butch
> comment with two tabs
>
> 1.6 08/01/07 07:58:16 butch
> comment with one tab
>
> 1.5 08/01/07 07:56:28 butch
> abcde
>
> 1.4 08/01/07 07:54:38 butch
> dsjkhfkjhdsfjhdshfjhdfkjhdshfadshf d
>
> 1.3 03/11/06 14:57:21 mueller
>
> 1.2 03/11/06 14:56:49 mueller
>
> 1.1 03/11/06 14:56:16 mueller
> date and time created 03/11/06 14:56:16 by mueller
>
> 13 lines
> end of screen--------------------------------------------------------
>
> In that case the version V1.1 to 1.3 were stored without any comment
>
> Your questions.
> 1. To simulate an I/O error on the l file I set it to unread- and unwritable
> (# chmod 000 l.P26J000001.input)
> Then issued the command
>
> storm_KPM> get -l SCCS/s.P26J000001.input
> the message on the screen is-------------
> 1.3
> 13 lines
> end osf message----------------------------
>
> It seems that there is no proper handling of that error wrt the l-file.
> The g-file (in this case P26J000001.input) is still created properly
>
> 2. The mode of the l-file is
> storm_KPM> ls -l P26J000001.input
> -r--r--r-- 1 butch 25 904 Jan 7 07:51 P26J000001.input
>
> 3. It is not possible to insert multiple lines as comments so there is
> no need to handle it.

Multi-line comments can be added either by using a backslash
interactively, or by using

delta -y "multi
line
comment"

> 4. Leading tabs see example B. above

I think your file has become corrupted; even the tabs that should be
there seem to be missing.

> 5. I have to investigate, I will come up later
>
> 6a. Your question :Another question: if more than one file is gotten,
> what does "get -L"
> do? Does the format change?
>
>
> storm_KPM> get -p -L SCCS/s.P26J000001.input

> 6b. get -L -p SCCS/s.P26J000001.input : no difference to 6a
>
> 7. Im not quite sure if I understand the questions. Why should be the
> l-file a
> broken symbolic link. It is created by the command as a file and not as a
> link.

ln -s l.foo thisfiledoesnotexist
get -lp s.foo

Here l.foo starts off as a broken link. The question is, does l.foo
get deleted and recreated, or is the symlink followed, creating
thisfiledoesnotexist?

> 8. more files:
> storm_KPM> get -L SCCS/s.P26J000001.input SCCS/s.P26J000000.input
[...]
> hence, it displays both outputs one after another
> please note that there are no comments in the second file
>
> The format does not change
>
>
> I hope I met your questions

Thanks; as far as I can tell, the existing CSSC implementation works
in the same way.

> Enclosed
> - the man pages from the get command (just in case I didn't send it alread)

I have read the manual pages; they are available on-line, for example.
But they are not useful for making documentation for CSSC, as the
copyright in those files belongs to HP (I assume), not to the FSF or
you. But thanks anyway.

James.

_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

Re: Implementing "get -l" (was: Re: CSSC)

2008-01-06T04:37:12Z

On Jan 5, 2008 8:02 PM, James Youngman <jay@...> wrote:
> In pursuit of which, I have some questions. Could you address these
> in your specification?

I have checked a preliminary implementation into CVS. See
http://savannah.gnu.org/cvs/?group=cssc for information on how to
build CSSC from CVS. The code is not fully ready for release yet,
because some of the questions below remain unanswered:

> 1. How does SCCS handle an I/O error on the l-file? Is the l-file
> deleted? What happens to the g-file?

I still need an answer to this.

> 2. What mode is the l-file created with (don't forget to take account
> of the umask)?

I still need an answer to this.

> 3. How are multiline comments handled? Do they have a tab-prefix, or not?
> 4. Are leading tabs in the comments handled specially?
> 5. What about MR numbers, flags, and included/excluded deltas? If a
> change has any of those, are they printed? In what order? How are
> they represented?

The implementation makes a guess at these, but we still need an answer
to all of them.

> 6. What does "get -p -L" do? How about "get -L -p"?

I believe I have resolved this (the delta summary goes to stderr in
both cases), but this could stand a little checking.

> 7. If l.foo is a broken symbolic link, does "get -l s.foo" follow it?

I still need an answer to this.

James.

_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

Re: Implementing "get -l" (was: Re: CSSC)

2008-01-05T12:56:01Z

Another question: if more than one file is gotten, what does "get -L"
do? Does the format change?

_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

Re: Implementing "get -l" (was: Re: CSSC)

2008-01-05T12:02:05Z

On Jan 5, 2008 7:01 PM, James Youngman <jay@...> wrote:
> I'm copying my email to the bug-cssc mailing list; please copy the
> mailing list when replying, since other members of the list may also
> be able to help.

In pursuit of which, I have some questions. Could you address these
in your specification?

1. How does SCCS handle an I/O error on the l-file? Is the l-file
deleted? What happens to the g-file?
2. What mode is the l-file created with (don't forget to take account
of the umask)?
3. How are multiline comments handled? Do they have a tab-prefix, or not?
4. Are leading tabs in the comments handled specially?
5. What about MR numbers, flags, and included/excluded deltas? If a
change has any of those, are they printed? In what order? How are
they represented?
6. What does "get -p -L" do? How about "get -L -p"?
7. If l.foo is a broken symbolic link, does "get -l s.foo" follow it?

Thanks,
James.

_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

Implementing "get -l" (was: Re: CSSC)

2008-01-05T11:01:33Z

I'm copying my email to the bug-cssc mailing list; please copy the
mailing list when replying, since other members of the list may also
be able to help.

On Jan 5, 2008 4:43 PM, Klaus Metzger <klaus.metzger@...> wrote:

> James Youngman schrieb:
>
> > On Dec 15, 2007 2:46 PM, Klaus Metzger <klaus.metzger@...> wrote:
> >
> >> Hello James,
> >> how are you?
> >> I would like to know what the status of the get -l option is you are
> >> about to develop for the CSSC?
> >>
> >
> > I haven't worked on it.
> >
> >
> >> It would have been helpful for me already several times if I had had it.
> >>
> >
> > I understand. You might want to mail the list too, in case anyone
> > else wants to help.
> >
> > James.
> >
> >
> Hello James,
> no. I wanted to say that I needed it already several times, but didn't
> have it.
> Do you think you will have time sooner or later to make it?
> Thanks
> Klaus
>
>

I have been able to devote very little time to this.

Reading over the materials you sent, I note that we still need answers
to these questions from February:

<< The reason that "get -l" is not implemented at in CSSC the moment is
simply that no specification exists for the format of the output and
the Unix documentation doesn't state how the -l and -lp options
interact with the other possible options to the "get" command. For
example, what's the precise effect of "-l -e", and how does "-lp"
interact with the "-g" and "-p" options? There are likely to be
other cases where the behaviour needs to be specified, too. >>

Also, I wrote:

<< So, if you would like to document that in sufficient detail to make it
possible to implement the feature, I'm happy to write the code
implementing the options you need. >>

We still don't have any documentation for this, though. (You did
provide me with part of a Tru64 Unix manual page, but obviously the
FSF cannot distribute that, we need documentation which is not copied
or derived from that information).

Meanwhile, I'm making a start on the code. I hope you will see some
changes in the CVS tree (http://savannah.gnu.org/cvs/?group=cssc).
To finish the code changes, we need more information though. And to
make a release containing those code changes, we need documentation.

Thanks,
James.

_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

Question about ancient releases of CSSC

2007-12-22T04:27:09Z

Does anybody have a historical copy of any of the following releases
of CSSC? I don't have a copy of the release file, and nor does
SourceForge. I'm currently assuming that they were release
candidates that I decided not to release, but I'd like to be sure.

CSSC-0.06alpha-pl8
CSSC-0.04alpha-pl0
CSSC-0.03alpha-pl2
CSSC-0.03alpha-pl1
CSSC-0.03alpha-pl0
CSSC-0.01-devel-p6
CSSC-0.01-devel-p5
CSSC-0.01-devel-p4

Thanks,
James.

_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

Re: Moving to CSSC

2007-12-18T16:28:45Z

On Dec 18, 2007 10:37 PM, Geoff Hull <gbh@...> wrote:
> I probably won't get back to this until 3 weeks hence, unfortunately. But will definitely will
> follow it up.

I understand. Should you wish to add a bug at
http://savannah.gnu.org/bugs/?func=additem&group=cssc to act as a
placeholder until then, that would be handy; it would serve to make
sure we don't entirely forget the problem :)

Thanks,
James.

_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

Re: Moving to CSSC

2007-12-18T14:37:16Z

James,

I have been on leave for 2 days.

> > I have included some attached files with are the IP of the company I
> > work for.
> >
> > I'll send a copy without the files to the mailing list separately. Can
> > you please treat these files as confidential and delete them when you
> > have finished with them. I'm being super paranoid here, but want to give
> > my employers some peace of mind.
>
> Please don't do this! I don't want to see your confidential
> material, and neither should you be forced to divulge it in order to
> get help.
>
> Instead, use the file "testutils/mogrify.awk" in the CSSC distribution to
> delete the actual body lines of the SCCS files. That will expunge the
> problematic content of the files. The comments are left intact however,
> so please double-check those for any information you wouldn't want to be
> made public.

That sounds like a better solution. In actual fact the amount of proprietary code is tiny and
would be totally useless without the other 13,000 odd files.

I probably won't get back to this until 3 weeks hence, unfortunately. But will definitely will
follow it up.

>
> I think you should be able to reproduce the behaviour you're talking
> about on the "mogrified" version of the files.
>
> Please note also though that the GNU Project prefers not to use the
> term "Intellectual Property" as it represents a confusion between two
> concepts that are in fact distinct; see
> http://www.gnu.org/philosophy/words-to-avoid.html#IntellectualProperty for
> a brief explanation.

Thanks, I'll have a look at it. I have a lot of respect for the opinions of the FSF.

>
> Thanks,
> James.

Geoff

_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

Re: Announcing the release of CSSC version 1.1.0

2007-12-18T01:33:22Z

On Dec 17, 2007 11:45 PM, James Youngman <jay@...> wrote:
> Please report any bugs via this software to the CSSC bug reporting
> page, http://savannah.gnu.org/bugs/?group=findutils

Sorry. That URL should be https://savannah.gnu.org/bugs/?group=cssc.

James.

_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

Announcing the release of CSSC version 1.1.0

2007-12-17T15:45:49Z

I'm pleased to announce the release of GNU CSSC, version
1.1.0.

This is a test release and so it is available from
ftp://alpha.gnu.org/gnu/cssc.

CSSC ("Compatibly Stupid Source Control") is the GNU
project's replacement for the traditional Unix SCCS suite.
It aims for full compatibility, including precise nuances of
behaviour, support for all command-line options, and in most
cases bug-for-bug compatibility. CSSC comes with an
extensive automated test suite.

If you are currently using SCCS to do version control of
software, you should be able to just drop in CSSC, even for
example if you have a large number of shell scripts which
are layered on top of SCCS and depend on it. This should
allow you to develop on and for the GNU/Linux platform if
your source code exists only in an SCCS repository. CSSC
also allows you to migrate to a more modern version control
system (such as CVS, perhaps).

There is a mailing list for users of the CSSC suite. To
join it, please send email to <cssc-users-request@...>
or visit the URL
http://lists.gnu.org/mailman/listinfo/cssc-users.

In the file docs/CREDITS within the CSSC distribution, there
is a full list of people who have contributed to the
development of CSSC. They are listed briefly here :-

James Youngman, Ross Ridge, Eric Allman, Lars Hecking,
Larry McVoy, Dave Bodenstab, Malcolm Boff, Richard Polton,
Fila Kolodny, Peter Kjellerstedt, John Interrante,
Marko Rauhamaa, Achim Hoffann, Dick Streefland,
Greg A. Woods, Aron Griffis, Michael Sterrett,
William W. Austin, Hyman Rosen, Mark Reynolds,
Sergey Ostashenko, Frank van Maarseveen, Jeff Sheinberg,
Thomas Duffy, Yann Dirson

Many thanks to all the above people.

New in CSSC-1.1.0, 2007-12-17

* GNU CSSC is now distributed under version 3 of the GNU General
Public License. The documentation is distributed under
version 1.2 of the GNU Free Documentation License.

* We now require the C++ compiler to support exceptions in
order to compile successfully. Previously, CSSC allowed
compilation without exceptions, but this meant that graceful
recovery from failures was not possible.

* Fixed a spurious failure when writing out the SCCS file when
the Y flag is set in the SCCS file.

* "sccs unedit /tmp/SCCS/s.foo" will no longer cause the
deletion of ./s.foo, if it exists. Instead, ./foo will be
deleted, as intended.

* Support for some older SCCS files as produced by Unix System III
(some of these have leading spaces in the counts of inserted/
deleted/unchanged lines in the delta table).

* Compilation fixes for Darwin

Please report any bugs via this software to the CSSC bug reporting
page, http://savannah.gnu.org/bugs/?group=findutils

_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

Migrating from SCCS (to GIT)

2007-12-16T16:53:57Z

On Dec 16, 2007 10:05 PM, Geoff Hull <gbh@...> wrote:

> Just another note - I note that there is a "to do" to rewrite the sccs2rcs script. An IBM
> employee - Jonathon Leffler - has already done this, and included it in his "sccstools"
> package.

Interesting, I will try to find time to take a look.

While I'm thinking about migration, I made a start a few weeks back on
a tool for migrating from SCCS direct to GIT. Is anyone interested in
testing such a thing?

James.

_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

Re: Moving to CSSC

2007-12-16T16:29:43Z

On Dec 16, 2007 10:05 PM, Geoff Hull <gbh@...> wrote:
> And you did a very good job of it, I must say!

Thanks.

> > Watch out for automatic OS upgrades :)
>
> We only use CSSC on Linux and it doesn't come with SCCS (obviously), so it would only
> happen when we upgraded CSSC.

Yes, but CSSC is included with many Linux distributions, for example
Debian GNU/Linux, so this problem may bite you when you apply OS
updates to your Linux systems.

Thanks,
James.

_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

Re: Moving to CSSC

2007-12-16T16:19:02Z

On Dec 16, 2007 10:05 PM, Geoff Hull <gbh@...> wrote:
> That was a speedy response!
>
> I have included some attached files with are the IP of the company I work for.
>
> I'll send a copy without the files to the mailing list separately. Can you please treat these
> files as confidential and delete them when you have finished with them. I'm being super
> paranoid here, but want to give my employers some peace of mind.

Please don't do this! I don't want to see your confidential
material, and neither should you be forced to divulge it in order to
get help.

Instead, use the file "testutils/mogrify.awk" in the CSSC distribution
to delete the actual body lines of the SCCS files. That will expunge
the problematic content of the files. The comments are left intact
however, so please double-check those for any information you wouldn't
want to be made public.

I think you should be able to reproduce the behaviour you're talking
about on the "mogrified" version of the files.

Please note also though that the GNU Project prefers not to use the
term "Intellectual Property" as it represents a confusion between two
concepts that are in fact distinct; see
http://www.gnu.org/philosophy/words-to-avoid.html#IntellectualProperty
for a brief explanation.

Thanks,
James.

_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

Missing Links

2007-12-16T14:09:17Z

Sorry, when I did a copy to the mailing list, it was sent as plain text and the links
disappeared.

The web page where Jonathan Leffler mentions his sccstools is this one:

http://svn.haxx.se/users/archive-2004-06/0158.shtml

and the download link is this one:

http://home.earthlink.net/~jleffler/JLSS/sccstools-3.00.tgz

Geoff

_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

Re: Moving to CSSC

2007-12-16T14:05:11Z

That was a speedy response!

I have included some attached files with are the IP of the company I work for.

I'll send a copy without the files to the mailing list separately. Can you please treat these
files as confidential and delete them when you have finished with them. I'm being super
paranoid here, but want to give my employers some peace of mind.

> On Dec 13, 2007 9:27 PM, Geoff Hull <gbh@...> wrote:
> >
> >
> > Greetings all!
> >
> >
> > We are a COBOL software development company (now moving to Java) and we
> > moved to using a Red Hat Enterprise Linux server as our main machine at
> > the beginning of this year. We did some trials before moving to Linux,
> > to see if there were likely to be any major problems with using CSSC. We
> > didn't find any.
>
> I'm not surprised. I was in the same position just over ten years
> ago and built CSSC to do the migration :)

And you did a very good job of it, I must say!

>
> > We copied our 20 years of SCCS files to our new RHEL 4.4 server and
> > started
> > using CSSC in earnest. There were some minor differences between UNIX
> > SCCS and CSSC, but we use a wrapper script (called sccs) so didn't have
> > any problems with dealing with these.
>
> > Our move to CSSC has been remarkably trouble-free.
>
> I'm very glad to hear this.
>
> > It is slightly more fussy about file layout,
>
> Any difference there is almost certainly a bug. Do you have enough
> remaining information to be more precise about the differences there?
>

Mainly the space before the date issue. A sample file s.uwadvc.fil is attached. Line 244 is
the offender. SCCS on Solaris 10 will handle this.

>
> > but we've only had to "fix" about a dozen files out
> > of nearly 13,000. We have been using CSSC exclusively for nearly a year
> > now.
>
> Congratulations and thanks for letting us all know.
>
> > File Problems
> >
> >
> > 1. Our file problems stem from allowing our programmers to manually
> > edit
> > the SCCS/s.<filename> file and then do "admin -z" on it (to recalculate
> > the checksum).
>
> So you're pretty sure that the format problems you describe were
> manually introduced, and not compatibility issues?
>
> Also, I'm morbidly curious: why do your programmers need to do this?
> The only time I have needed to manually edit SCCS files was to fix the
> history files which had been corrupted by a non-y2k-compliant version of
> SCCS on Dynix.
>

Hmmm. Yes, we have had some rogue programmers. Some of them got into the habit of
editing the SCCS file if they found they had branched a later version than they needed to.

Try "cssc get s.uwtotlnlth.sel" on the attached file. This works fine for Solaris 10 (and
previously HP-UX 11i v2 and AIX 5.3 - you do get a date warning on the latter). I think
there are some deleted revisions, followed by some "deleted" revisions.

Try the same "cssc get" for s.uwrgen.old and s.uwmtft.cbl.dck. They are also both okay
under Solaris 10 and AIX 5.3.

> >
> >
> > In two of our files we had an extra space before a date field on the
> > "d"
> > line, for example:
> >
> >
> > ^As 00034/00000/03110
> > ^Ad D 35.2 03/08/07 13:36:08 keith 70 69
> > ^Am 8447
> > ^Ac Add Location Co-ordinate Fields
> > ^Ae
>
> I see you have an MR number there. Do you use an MR validation
> script? Up to now, I haven't heard of anybody actually using one,
> though the functionality is well tested.
>

We don't use any validation script. I didn't realize we could until your question. We only
switched these on a couple of years ago. These correspond to our "IDs" which are really
job numbers I guess. We sometimes enter 2 or 3 MRs.

> > This gave us a message like:
> >
> >
> > prs: /s/uniworks/SCCS/s.uwclblr.prt: line 465: Corrupted SCCS file.
> > (Invalid number)
> >
> >
> > It was easily fixed - edit the file to remove the space and do an "
> > cssc
> > admin -z " on the file. (I had renamed /usr/bin/sccs to /usr/bin/cssc to
> > avoid conflicts with our sccs script.)
>
> Watch out for automatic OS upgrades :)

We only use CSSC on Linux and it doesn't come with SCCS (obviously), so it would only
happen when we upgraded CSSC.

>
>
> > 2. We also found problems in about 8 of our files where our programmers
> > had
> > manually removed some simple intermediate revisions from the SCCS file,
> > and had then run "admin -z" to fix the checksum. SCCS handles this but
> > CSSC doesn't. We fixed this by manually editing the file and creating
> > phony auto null deltas.
>
>
> This does sound like an incompatibility. It would be nice to fix it,
> though it sounds like you have resolved the problem.

See above.

>
>
> > Minor Differences
> >
> >
> > prs -d":T" - no space between the "-d" and the parameters
>
> Yes; modern implementations allow arguments to be separated from the
> options, though this is not the ancient behaviour. Back when I was
> migrating from SCCS, I was using scripts which used options without
> arguments to indicate the lack of a checkin comment, for example.
>
> I believe it probably would be useful to support modern argument
> interpretation, at least as a configure-time option. The problem
> though is that it is hard to figure out a change which exaclt
> minimised incompatibilities. Because of the risk of unexpected
> changes in behaviour I have simply avoid making any changes there.
>

Yes, I think that is probably not worth the effort.

> > CSSC's rmdel allows a person to delete a revision made by another
> > programmer
>
> I had no idea regular SCCS had this feature! Thanks for telling me!
> Do you have any idea how this interacts with the authorised-user
> list? I think this is a bug, too.

My apologies. I got this information second-hand. I just tried it here and got this with AT&T
SCCS (Solaris 10):
/data/tmp$ delta -m10056 s.uwadvc.fil
comments? deleted some lines
ERROR [s.uwadvc.fil]: login name or SID specified not in p-file (de2)

And with CSSC:
sam:/home/gbh/tmp>cssc delta -m10065 -y'nice one!' s.uwadvc.fil
delta: s.uwadvc.fil: You have no edits outstanding.

Might have been something else our wrapper script was doing.

>
> > CSSC's sccsdiff is better than SCCS at showing differences revisions
> > (doesn't show bogus differences like SCCS does).
>
> Curious; CSSC's sccsdiff doesn't try to be especially clever. Do you
> think there might be circumstances where the difference could be a
> problem?

I'm not sure, I'm going on what one of our programmers told me. I think it is something
that looks like changes in whitespace, but there aren't any changes. I think this has been
tested several times by getting the different versions out then doing a diff on them, which
showed that some of the differences were "phantoms".

>
> > CSSC's get command allows for editing (at the same time) of both the
> > main
> > and a branch. (We prevent this with our sccs wrapper script, so it
> > doesn't affect us.)
>
> [frown.] I didn't know this was not supposed to be possible. Could
> you please please please try to make a test script which succeeds with
> "real" SCCS but fails with CSSC?

Sorry, another thing our script has always stopped us from doing. When I tested this here
myself, it works identically for both SCCS and CSSC.

>
>
> > PRS Bug
> >
> >
> > One difference between GNU CSSC and AT&T SCCS is in what is displayed
> > for
> > the command "sccs prs -l <s.file>". SCCS gives only the latest revision
> > whereas CSSC also includes all the auto null delta revisions (if
> > present) as well.
> >
> >
> > James, should I register this as a bug on SourceForge as well?
>
> Please do; it certainly sounds like a bug!
>
> James.

Using the attached s.uwadvc.fil (you will have to take a copy and edit it to remove the
extra space, then do "admin -z"), if you do these commands, you'll see what I mean:

/home/gbh/tmp$ cssc rmdel -r43.2 s.uwadvc.fil
/home/gbh/tmp$ cssc prs -l s.uwadvc.fil

Just another note - I note that there is a "to do" to rewrite the sccs2rcs script. An IBM
employee - Jonathon Leffler - has already done this, and included it in his "sccstools"
package.

I found it on this page . He says he has made some improvements to it, such as not
getting any source code out of SCCS files to convert them. There is a download link on
that page. He may be willing to allow a link to his page from the CSSC web page.

Geoff

_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

The CVS repository for GNU CSSC has moved

2007-12-16T03:48:33Z

I have moved the CVS repository for GNU CVS from Sourceforge to the
GNU Project's own Savannah site. Please see
http://savannah.gnu.org/cvs/?group=cssc for details of how to use the
new CVS repository.

The old repository still exists for now, but contains just a pointer
to the new one.

Thanks,
James.

_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

Re: Moving to CSSC

2007-12-13T14:22:26Z

On Dec 13, 2007 9:27 PM, Geoff Hull <gbh@...> wrote:

>
>
> Greetings all!
>
>
> We are a COBOL software development company (now moving to Java) and we
> moved to using a Red Hat Enterprise Linux server as our main machine at the
> beginning of this year. We did some trials before moving to Linux, to see if
> there were likely to be any major problems with using CSSC. We didn't find
> any.

I'm not surprised. I was in the same position just over ten years
ago and built CSSC to do the migration :)

> We copied our 20 years of SCCS files to our new RHEL 4.4 server and started
> using CSSC in earnest. There were some minor differences between UNIX SCCS
> and CSSC, but we use a wrapper script (called sccs) so didn't have any
> problems with dealing with these.

> Our move to CSSC has been remarkably trouble-free.

I'm very glad to hear this.

> It is slightly more fussy about file layout,

Any difference there is almost certainly a bug. Do you have enough
remaining information to be more precise about the differences there?

> but we've only had to "fix" about a dozen files out
> of nearly 13,000. We have been using CSSC exclusively for nearly a year now.

Congratulations and thanks for letting us all know.

> File Problems
>
>
> 1. Our file problems stem from allowing our programmers to manually edit
> the SCCS/s.<filename> file and then do "admin -z" on it (to recalculate the
> checksum).

So you're pretty sure that the format problems you describe were
manually introduced, and not compatibility issues?

Also, I'm morbidly curious: why do your programmers need to do this?
The only time I have needed to manually edit SCCS files was to fix the
history files which had been corrupted by a non-y2k-compliant version
of SCCS on Dynix.

>
>
> In two of our files we had an extra space before a date field on the "d"
> line, for example:
>
>
> ^As 00034/00000/03110
> ^Ad D 35.2 03/08/07 13:36:08 keith 70 69
> ^Am 8447
> ^Ac Add Location Co-ordinate Fields
> ^Ae

I see you have an MR number there. Do you use an MR validation
script? Up to now, I haven't heard of anybody actually using one,
though the functionality is well tested.

> This gave us a message like:
>
>
> prs: /s/uniworks/SCCS/s.uwclblr.prt: line 465: Corrupted SCCS file.
> (Invalid number)
>
>
> It was easily fixed - edit the file to remove the space and do an " cssc
> admin -z " on the file. (I had renamed /usr/bin/sccs to /usr/bin/cssc to
> avoid conflicts with our sccs script.)

Watch out for automatic OS upgrades :)

> 2. We also found problems in about 8 of our files where our programmers had
> manually removed some simple intermediate revisions from the SCCS file, and
> had then run "admin -z" to fix the checksum. SCCS handles this but CSSC
> doesn't. We fixed this by manually editing the file and creating phony auto
> null deltas.

This does sound like an incompatibility. It would be nice to fix it,
though it sounds like you have resolved the problem.

> Minor Differences
>
>
> prs -d":T" - no space between the "-d" and the parameters

Yes; modern implementations allow arguments to be separated from the
options, though this is not the ancient behaviour. Back when I was
migrating from SCCS, I was using scripts which used options without
arguments to indicate the lack of a checkin comment, for example.

I believe it probably would be useful to support modern argument
interpretation, at least as a configure-time option. The problem
though is that it is hard to figure out a change which exaclt
minimised incompatibilities. Because of the risk of unexpected
changes in behaviour I have simply avoid making any changes there.

> CSSC's rmdel allows a person to delete a revision made by another
> programmer

I had no idea regular SCCS had this feature! Thanks for telling me!
Do you have any idea how this interacts with the authorised-user
list? I think this is a bug, too.

> CSSC's sccsdiff is better than SCCS at showing differences revisions
> (doesn't show bogus differences like SCCS does).

Curious; CSSC's sccsdiff doesn't try to be especially clever. Do you
think there might be circumstances where the difference could be a
problem?

> CSSC's get command allows for editing (at the same time) of both the main
> and a branch. (We prevent this with our sccs wrapper script, so it doesn't
> affect us.)

[frown.] I didn't know this was not supposed to be possible. Could
you please please please try to make a test script which succeeds with
"real" SCCS but fails with CSSC?

> PRS Bug
>
>
> One difference between GNU CSSC and AT&T SCCS is in what is displayed for
> the command "sccs prs -l <s.file>". SCCS gives only the latest revision
> whereas CSSC also includes all the auto null delta revisions (if present) as
> well.
>
>
> James, should I register this as a bug on SourceForge as well?

Please do; it certainly sounds like a bug!

James.

_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

Moving to CSSC

2007-12-13T13:27:55Z

Greetings all!

We are a COBOL software development company (now moving to Java) and we moved to using a Red Hat Enterprise Linux server as our main machine at the beginning of this year. We did some trials before moving to Linux, to see if there were likely to be any major problems with using CSSC. We didn't find any.

We copied our 20 years of SCCS files to our new RHEL 4.4 server and started using CSSC in earnest. There were some minor differences between UNIX SCCS and CSSC, but we use a wrapper script (called sccs) so didn't have any problems with dealing with these.

Our move to CSSC has been remarkably trouble-free. It is slightly more fussy about file layout, but we've only had to "fix" about a dozen files out of nearly 13,000. We have been using CSSC exclusively for nearly a year now.

File Problems

1. Our file problems stem from allowing our programmers to manually edit the SCCS/s.<filename> file and then do "admin -z" on it (to recalculate the checksum).

In two of our files we had an extra space before a date field on the "d" line, for example:

^As 00034/00000/03110

^Ad D 35.2 03/08/07 13:36:08 keith 70 69

^Am 8447

^Ac Add Location Co-ordinate Fields

^Ae

This gave us a message like:

prs: /s/uniworks/SCCS/s.uwclblr.prt: line 465: Corrupted SCCS file. (Invalid number)

It was easily fixed - edit the file to remove the space and do an " cssc admin -z " on the file. (I had renamed /usr/bin/sccs to /usr/bin/cssc to avoid conflicts with our sccs script.)

2. We also found problems in about 8 of our files where our programmers had manually removed some simple intermediate revisions from the SCCS file, and had then run "admin -z" to fix the checksum. SCCS handles this but CSSC doesn't. We fixed this by manually editing the file and creating phony auto null deltas.

Minor Differences

prs -d":T" - no space between the "-d" and the parameters

CSSC's rmdel allows a person to delete a revision made by another programmer

CSSC's sccsdiff is better than SCCS at showing differences revisions (doesn't show bogus differences like SCCS does).

CSSC's get command allows for editing (at the same time) of both the main and a branch. (We prevent this with our sccs wrapper script, so it doesn't affect us.)

PRS Bug

One difference between GNU CSSC and AT&T SCCS is in what is displayed for the command "sccs prs -l <s.file>". SCCS gives only the latest revision whereas CSSC also includes all the auto null delta revisions (if present) as well.

James, should I register this as a bug on SourceForge as well?

Regards,

Geoff Hull

Internal Support

McCarthy Associates

Hastings, New Zealand

_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

Problems installing CSSC

2007-10-10T10:31:14Z

Hello,

I'm having some problems installing CSSC (v.1.0.1) in a linux box, at the "make" stage. I attatch the output, in hopes you can take a look and guide me through this.

Should you need more feedback, let me know.

Specs: Suse Linux 10.2, perl 5.8.8, kernel version 2.6.18.8-0.3-default

Thanks in advance.

---Begin output---
sised01218:~/Instalaciones/CSSC-1.0.1 # make check
make check-recursive
make[1]: Entering directory `/root/Instalaciones/CSSC-1.0.1'
Making check in bsd
make[2]: Entering directory `/root/Instalaciones/CSSC-1.0.1/bsd'
if gcc -DHAVE_CONFIG_H -I. -I. -I.. "-DPREFIX=\"/usr/local/libexec/cssc/\"" -g -MT sccs.o -MD -MP -MF ".deps/sccs.Tpo" \
-c -o sccs.o `test -f 'sccs.c' || echo './'`sccs.c; \
then mv -f ".deps/sccs.Tpo" ".deps/sccs.Po"; \
else rm -f ".deps/sccs.Tpo"; exit 1; \
fi
In file included from /usr/include/stdio.h:34,
from sccs.c:54:
/usr/lib64/gcc/x86_64-suse-linux/4.1.2/include/stddef.h:214: error: duplicate ‘unsigned’
In file included from /usr/include/stdlib.h:438,
from sccs.c:63:
/usr/include/sys/types.h:72: error: two or more data types in declaration specifiers
/usr/include/sys/types.h:100: error: two or more data types in declaration specifiers
sccs.c:1696: warning: ‘struct direct’ declared inside parameter list
---End output---

Migrating CSSC to GNU Savannah

2007-06-26T17:31:09Z

I plan to migrate the SourceForge project resources for CSSC (the bug
tracker and web pages particularly) to the GNU site,
http://savannah.gnu.org/.

Does anybody have any comments or objections?

James.

_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

Proposal: move CSSC development from SourceForge to GNU project's Savannah site

2007-03-23T03:13:00Z

I propose to move development of GNU CSSC from Sourceforge to the GNU
project's own website, Savannah. This also features a bug tracker,
mailing lists, CVS browse access, and so forth. Savannah is at
http://savannah.gnu.org/

Any objections?

James.

_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

Google's Summer of Code 2007 programme is under way

2007-03-04T05:34:05Z

The GNU project is participating in Google's Summer of Code programme
in 2007. We also participated in 2006.

The page at http://www.gnu.org/software/soc-projects/ideas.html
contains a couple of suggestions for Summer of Code projects which
relate to CSSC.

If you have suggestions for other CSSC projects or comments on the
existing ideas, please send them to the cssc-users@... mailing
list. If you have suggestions for other GNU projects, please discuss
them with the developer communities for those projects. If you have
comments on or questions about the GNU Project's involvement in the
Google Summer of Code programme, please email summer-of-code@....

Thanks,
James.

_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users

Re: CSSC

2007-02-22T09:30:56Z

On 2/5/07, butch2005 <butch2005@...> wrote:

>
> Message body follows:
>
> Hi,
> I'm using, or better I'm migrating from TruUnix64-SCCS to
> CSSC (compiled on a Ubuntu system). Up to now it works good
> and I'm happy with it.
> One command I would need is the "get -l" commnd. This
> option is not implemented according to your README file. Is
> there a chance that it will be implemented in a future
> release? I find the command option very helpful.
> Thanks a lot
> Klaus Metzger
> Germany

The reason that "get -l" is not implemented at in CSSC the moment is
simply that no specification exists for the format of the output and
the Unix documentation doesn't state how the -l and -lp options
interact with the other possible options to the "get" command. For
example, what's the precise effect of "-l -e", and how does "-lp"
interact with the "-g" and "-p" options? There are likely to be
other cases where the behaviour needs to be specified, too.

So, if you would like to document that in sufficient detail to make it
possible to implement the feature, I'm happy to write the code
implementing the options you need. Be advised though that your
documentation enhancement to CSSC is likely to be significant enough
for it to be necessary for you to assign copyright in your change to
the Free Software Foundation. I hope that's OK.

Thanks,
James.

_______________________________________________
cssc-users mailing list
cssc-users@...
http://lists.gnu.org/mailman/listinfo/cssc-users