On Wed, Apr 15, 2009 at 12:28 AM, Geoff Hull <g...@mccarthy.co.nz> 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@gnu.org http://lists.gnu.org/mailman/listinfo/cssc-users
