head	1.2;
access;
symbols
	RELENG_8_4:1.1.1.9.0.18
	RELENG_9_1_0_RELEASE:1.1.1.9
	RELENG_9_1:1.1.1.9.0.16
	RELENG_9_1_BP:1.1.1.9
	RELENG_8_3_0_RELEASE:1.1.1.9
	RELENG_8_3:1.1.1.9.0.14
	RELENG_8_3_BP:1.1.1.9
	RELENG_9_0_0_RELEASE:1.1.1.9
	RELENG_9_0:1.1.1.9.0.12
	RELENG_9_0_BP:1.1.1.9
	RELENG_9:1.1.1.9.0.10
	RELENG_9_BP:1.1.1.9
	RELENG_7_4_0_RELEASE:1.1.1.7.18.1
	RELENG_8_2_0_RELEASE:1.1.1.9
	RELENG_7_4:1.1.1.7.18.1.0.8
	RELENG_7_4_BP:1.1.1.7.18.1
	RELENG_8_2:1.1.1.9.0.8
	RELENG_8_2_BP:1.1.1.9
	RELENG_8_1_0_RELEASE:1.1.1.9
	RELENG_8_1:1.1.1.9.0.6
	RELENG_8_1_BP:1.1.1.9
	RELENG_7_3_0_RELEASE:1.1.1.7.18.1
	RELENG_7_3:1.1.1.7.18.1.0.6
	RELENG_7_3_BP:1.1.1.7.18.1
	RELENG_8_0_0_RELEASE:1.1.1.9
	RELENG_8_0:1.1.1.9.0.4
	RELENG_8_0_BP:1.1.1.9
	RELENG_8:1.1.1.9.0.2
	RELENG_8_BP:1.1.1.9
	RELENG_7_2_0_RELEASE:1.1.1.7.18.1
	RELENG_7_2:1.1.1.7.18.1.0.4
	RELENG_7_2_BP:1.1.1.7.18.1
	RELENG_7_1_0_RELEASE:1.1.1.7.18.1
	RELENG_6_4_0_RELEASE:1.1.1.7
	RELENG_7_1:1.1.1.7.18.1.0.2
	RELENG_7_1_BP:1.1.1.7.18.1
	RELENG_6_4:1.1.1.7.0.24
	RELENG_6_4_BP:1.1.1.7
	v1_11_20080310:1.1.1.9
	RELENG_7_0_0_RELEASE:1.1.1.7
	RELENG_6_3_0_RELEASE:1.1.1.7
	v1_11_22:1.1.1.8
	PRE_1_11_22:1.1.1.7
	RELENG_7_0:1.1.1.7.0.22
	RELENG_7_0_BP:1.1.1.7
	RELENG_6_3:1.1.1.7.0.20
	RELENG_6_3_BP:1.1.1.7
	RELENG_7:1.1.1.7.0.18
	RELENG_7_BP:1.1.1.7
	RELENG_6_2_0_RELEASE:1.1.1.7
	RELENG_6_2:1.1.1.7.0.16
	RELENG_6_2_BP:1.1.1.7
	RELENG_5_5_0_RELEASE:1.1.1.7
	RELENG_5_5:1.1.1.7.0.14
	RELENG_5_5_BP:1.1.1.7
	RELENG_6_1_0_RELEASE:1.1.1.7
	RELENG_6_1:1.1.1.7.0.12
	RELENG_6_1_BP:1.1.1.7
	RELENG_6_0_0_RELEASE:1.1.1.7
	RELENG_6_0:1.1.1.7.0.10
	RELENG_6_0_BP:1.1.1.7
	RELENG_6:1.1.1.7.0.8
	RELENG_6_BP:1.1.1.7
	RELENG_5_4_0_RELEASE:1.1.1.7
	RELENG_5_4:1.1.1.7.0.6
	RELENG_5_4_BP:1.1.1.7
	RELENG_4_11_0_RELEASE:1.1.1.4.2.3
	RELENG_4_11:1.1.1.4.2.3.0.2
	RELENG_4_11_BP:1.1.1.4.2.3
	RELENG_5_3_0_RELEASE:1.1.1.7
	RELENG_5_3:1.1.1.7.0.4
	RELENG_5_3_BP:1.1.1.7
	RELENG_5:1.1.1.7.0.2
	RELENG_5_BP:1.1.1.7
	v1_11_17:1.1.1.7
	RELENG_4_10_0_RELEASE:1.1.1.4.2.2
	RELENG_4_10:1.1.1.4.2.2.0.6
	RELENG_4_10_BP:1.1.1.4.2.2
	v1_11_15:1.1.1.6
	RELENG_5_2_1_RELEASE:1.1.1.6
	RELENG_5_2_0_RELEASE:1.1.1.6
	RELENG_5_2:1.1.1.6.0.6
	RELENG_5_2_BP:1.1.1.6
	RELENG_4_9_0_RELEASE:1.1.1.4.2.2
	RELENG_4_9:1.1.1.4.2.2.0.4
	RELENG_4_9_BP:1.1.1.4.2.2
	RELENG_5_1_0_RELEASE:1.1.1.6
	RELENG_5_1:1.1.1.6.0.4
	RELENG_5_1_BP:1.1.1.6
	RELENG_4_8_0_RELEASE:1.1.1.4.2.2
	RELENG_4_8:1.1.1.4.2.2.0.2
	RELENG_4_8_BP:1.1.1.4.2.2
	v1_11_5:1.1.1.6
	RELENG_5_0_0_RELEASE:1.1.1.6
	RELENG_5_0:1.1.1.6.0.2
	RELENG_5_0_BP:1.1.1.6
	v1_11_2_1_20021201:1.1.1.6
	RELENG_4_7_0_RELEASE:1.1.1.4.2.1
	RELENG_4_7:1.1.1.4.2.1.0.10
	RELENG_4_7_BP:1.1.1.4.2.1
	v1_11_2:1.1.1.6
	RELENG_4_6_2_RELEASE:1.1.1.4.2.1
	RELENG_4_6_1_RELEASE:1.1.1.4.2.1
	RELENG_4_6_0_RELEASE:1.1.1.4.2.1
	RELENG_4_6:1.1.1.4.2.1.0.8
	RELENG_4_6_BP:1.1.1.4.2.1
	RELENG_4_5_0_RELEASE:1.1.1.4.2.1
	RELENG_4_5:1.1.1.4.2.1.0.6
	RELENG_4_5_BP:1.1.1.4.2.1
	RELENG_4_4_0_RELEASE:1.1.1.4.2.1
	RELENG_4_4:1.1.1.4.2.1.0.4
	RELENG_4_4_BP:1.1.1.4.2.1
	v1_11_1p1:1.1.1.5
	CVSHOME:1.1.1
	RELENG_4_3_0_RELEASE:1.1.1.4.2.1
	RELENG_4_3:1.1.1.4.2.1.0.2
	RELENG_4_3_BP:1.1.1.4.2.1
	RELENG_4_2_0_RELEASE:1.1.1.4.2.1
	v1_11:1.1.1.5
	RELENG_4_1_1_RELEASE:1.1.1.4
	PRE_SMPNG:1.1.1.4
	RELENG_4_1_0_RELEASE:1.1.1.4
	RELENG_3_5_0_RELEASE:1.1.1.3.2.1
	RELENG_4_0_0_RELEASE:1.1.1.4
	RELENG_4:1.1.1.4.0.2
	RELENG_4_BP:1.1.1.4
	RELENG_3_4_0_RELEASE:1.1.1.3.2.1
	v1_10_7:1.1.1.4
	RELENG_3_3_0_RELEASE:1.1.1.3
	RELENG_3_2_PAO:1.1.1.3.0.4
	RELENG_3_2_PAO_BP:1.1.1.3
	RELENG_3_2_0_RELEASE:1.1.1.3
	v1_10:1.1.1.3
	RELENG_3_1_0_RELEASE:1.1.1.3
	RELENG_3:1.1.1.3.0.2
	RELENG_3_BP:1.1.1.3
	RELENG_2_2_8_RELEASE:1.1.1.1.2.2
	RELENG_3_0_0_RELEASE:1.1.1.3
	RELENG_2_2_7_RELEASE:1.1.1.1.2.2
	RELENG_2_2_6_RELEASE:1.1.1.1.2.1
	v1_9_26:1.1.1.3
	v1_9_24:1.1.1.3
	v1_9_23_19980123:1.1.1.3
	RELENG_2_2_5_RELEASE:1.1.1.1.2.1
	v1_9_10:1.1.1.2
	v1_9_9_970523:1.1.1.2
	RELENG_2_2_2_RELEASE:1.1.1.1
	v1_9_9_970515:1.1.1.2
	RELENG_2_2_1_RELEASE:1.1.1.1
	RELENG_2_2_0_RELEASE:1.1.1.1
	RELENG_2_2:1.1.1.1.0.2
	RELENG_2_2_BP:1.1.1.1
	v1_8_1:1.1.1.1
	CYCLIC:1.1.1;
locks; strict;
comment	@# @;


1.2
date	2013.06.16.00.38.19;	author svnexp;	state dead;
branches;
next	1.1;

1.1
date	96.08.20.23.45.57;	author peter;	state Exp;
branches
	1.1.1.1;
next	;

1.1.1.1
date	96.08.20.23.45.57;	author peter;	state Exp;
branches
	1.1.1.1.2.1;
next	1.1.1.2;

1.1.1.2
date	97.05.15.22.45.02;	author peter;	state Exp;
branches;
next	1.1.1.3;

1.1.1.3
date	98.01.26.03.08.01;	author peter;	state Exp;
branches
	1.1.1.3.2.1;
next	1.1.1.4;

1.1.1.4
date	99.12.11.12.22.34;	author peter;	state Exp;
branches
	1.1.1.4.2.1;
next	1.1.1.5;

1.1.1.5
date	2000.10.02.06.31.00;	author peter;	state Exp;
branches;
next	1.1.1.6;

1.1.1.6
date	2002.09.02.05.49.40;	author peter;	state Exp;
branches;
next	1.1.1.7;

1.1.1.7
date	2004.06.10.19.05.37;	author peter;	state Exp;
branches
	1.1.1.7.18.1;
next	1.1.1.8;

1.1.1.8
date	2008.01.13.05.49.24;	author obrien;	state Exp;
branches;
next	1.1.1.9;

1.1.1.9
date	2008.03.19.14.46.51;	author obrien;	state Exp;
branches
	1.1.1.9.18.1;
next	;

1.1.1.1.2.1
date	97.06.28.03.21.22;	author peter;	state Exp;
branches;
next	1.1.1.1.2.2;

1.1.1.1.2.2
date	98.04.05.03.27.18;	author peter;	state Exp;
branches;
next	;

1.1.1.3.2.1
date	99.12.13.20.56.22;	author peter;	state Exp;
branches;
next	;

1.1.1.4.2.1
date	2000.10.31.09.37.43;	author obrien;	state Exp;
branches;
next	1.1.1.4.2.2;

1.1.1.4.2.2
date	2002.10.15.20.24.31;	author peter;	state Exp;
branches;
next	1.1.1.4.2.3;

1.1.1.4.2.3
date	2004.06.29.16.10.44;	author des;	state Exp;
branches;
next	;

1.1.1.7.18.1
date	2008.07.28.16.52.28;	author obrien;	state Exp;
branches;
next	;

1.1.1.9.18.1
date	2008.03.19.14.46.51;	author svnexp;	state dead;
branches;
next	1.1.1.9.18.2;

1.1.1.9.18.2
date	2013.03.28.13.00.40;	author svnexp;	state Exp;
branches;
next	;


desc
@@


1.2
log
@## SVN ## Exported commit - http://svnweb.freebsd.org/changeset/base/251794
## SVN ## CVS IS DEPRECATED: http://wiki.freebsd.org/CvsIsDeprecated
@
text
@How to write code for CVS

* Compiler options

If you are using GCC, you'll want to configure with -Wall, which can
detect many programming errors.  This is not the default because it
might cause spurious warnings, but at least on some machines, there
should be no spurious warnings.  For example:

	$ CFLAGS="-g -Wall" ./configure

Configure is not very good at remembering this setting; it will get
wiped out whenever you do a ./config.status --recheck, so you'll need
to use:

	$ CFLAGS="-g -Wall" ./config.status --recheck

* Indentation style

CVS mostly uses a consistent indentation style which looks like this:

void
foo (arg)
    char *arg;
{
    if (arg != NULL)
    {
	bar (arg);
	baz (arg);
    }
}

The file cvs-format.el contains settings for emacs and the NEWS file
contains a set of options for the indent program which I haven't tried
but which are correct as far as I know.  You will find some code which
does not conform to this indentation style; the plan is to reindent it
as those sections of the code are changed (one function at a time,
perhaps).

In a submitted patch it is acceptable to refrain from changing the
indentation of large blocks of code to minimize the size of the patch;
the person checking in such a patch should reindent it.

* Portability

If it is in ANSI C and it is in SunOS4 (using /bin/cc), generally it
is OK to use it without ifdefs (for example, assert() and void * as
long as you add more casts to and from void * than ANSI requires.  But
not function prototypes).  Such constructs are generally portable
enough, including to NT, OS/2, VMS, etc.

* Run-time behaviors

Use assert() to check "can't happen" conditions internal to CVS.  We
realize that there are functions in CVS which instead return NULL or
some such value (thus confusing the meaning of such a returned value),
but we want to fix that code.  Of course, bad input data, a corrupt
repository, bad options, etc., should always print a real error
message instead.

* Coding standards in general

Generally speaking the GNU coding standards are mostly used by CVS
(but see the exceptions mentioned above, such as indentation style,
and perhaps an exception or two we haven't mentioned).  This is the
file standards.text at the GNU FTP sites.

* Submitting patches

Please include a ChangeLog entry (see the GNU coding standards for
information on writing one) with patches.  Include a description of
what the patch does (sometimes the ChangeLog entry and/or comments in
the code are appropriate for this, but not always)--patches should not
be checked in unless there is some reason for them, and the
description may be helpful if there is a better way to solve the
problem.  In addition to the ChangeLog entry, there should be a change
to the NEWS file in the case of a new feature.

If you solve several unrelated problems, submit a separate
patch for each one.  Patches should be tested before submission.  Use
context diffs or unidiffs for patches.

Note that all submitted changes may be distributed under the terms of
the GNU Public License, so if you don't like this, don't submit them.
Submit changes to bug-cvs@@prep.ai.mit.edu.

Generally speaking if you follow the guidelines in this file you can
expect a yes or no answer about whether your patch is accepted.  But
even in this case there is no guarantee because wading through a bunch
of submissions can be time consuming, and noone has volunteered to
offer any such guarantee.  If you don't receive an answer one way or
another within a month, feel free to ask what the status is.  You can,
if you wish, distribute your patch on mailing lists or newsgroups, if
you want to make it available before it gets merged.

* What is the schedule for the next release?

There isn't one.  That is, upcoming releases are not announced (or
even hinted at, really) until the feature freeze which is
approximately 2 weeks before the final release (at this time test
releases start appearing and are announced on info-cvs).  This is
intentional, to avoid a last minute rush to get new features in.
@


1.1
log
@Initial revision
@
text
@@


1.1.1.1
log
@Import of slightly trimmed cvs-1.8 distribution.  Generated files
and non-unix code has been left out.
@
text
@@


1.1.1.1.2.1
log
@Update 2.2 to cvs-1.9.10 from -current (fixes a security problem with
pserver mode)
@
text
@d46 5
a50 11
The general rule for portability is that it is only worth including
portability cruft for systems on which people are actually testing and
using new CVS releases.  Without testing, CVS will fail to be portable
for any number of unanticipated reasons.

The current consequence of that general rule seems to be that if it
is in ANSI C and it is in SunOS4 (using /bin/cc), generally it is OK
to use it without ifdefs (for example, assert() and void * as long as
you add more casts to and from void * than ANSI requires.  But not
function prototypes).  Such constructs are generally portable enough,
including to NT, OS/2, VMS, etc.
a60 16
We realize that CVS contains many arbitrary limits (such as PATH_MAX).
Do not do this in new code; we are trying to *fix* those arbitrary
limits.  In particular, it should be possible to pass very long
arguments (e.g. from a WWW cgi script) to CVS without having it
overrun any buffers (which might create a security hole in the WWW
example).

Although this is a long-term goal, it also would be nice to move CVS
in the direction of reentrancy.  This reduces the size of the data
segment and will allow a multi-threaded server if that is desirable.
It is also useful to write the code so that it can be easily be made
reentrant later.  For example, if you need to pass data from a
Parse_Info caller to its callproc, you need a static variable.  But
use a single pointer so that when Parse_Info is fixed to pass along a
void * argument, then the code can easily use that argument.

d68 1
a68 38
Filenames for .c and .h files may contain _ but should not contain -
(the latter causes Visual C++ 2.1 to create makefiles which Visual C++
4.0 cannot use).

* Submitting patches (strategy)

Only some kinds of changes are suitable for inclusion in the
"official" CVS.  Bugfixes, where CVS's behavior contradicts the
documentation and/or expectations that everyone agrees on, should be
OK (strategically).  For features, the desirable attributes are that
the need is clear and that they fit nicely into the architecture of
CVS.

However, if there is reason to think that a change would significantly
inconvenience any significant body of CVS users, or would be
controversial for other reasons, then the design should be re-thought.
Go back to the requirements (writing documentation might help, if you
write the documentation to explain why one would use the feature not
just what the feature does).  Think about whether there is a behavior
which works in both your situation and the other situations.  Make a
list of the issues (for example, submit a comment or documentation
change).  Ask your coworkers, a newsgroup, or a mailing list, and see
what other people think.  Distribute some experimental patches outside
the "official" CVS and see what people think.  By this process, the
intention is that once-controversial changes can be refined to the
point where they are relatively uncontroversial before they are
actually checked in to the "official" CVS.  Features like zlib,
encryption, and others have benefitted from this process in the past
by being mentioned in the documentation and/or discussed, before an
implementation was checked in.

If longstanding CVS behavior, that people may be relying on, is
clearly deficient, it can be changed, but only slowly and carefully.
For example, the global -q option was introduced in CVS 1.3 but the
command -q options, which the global -q replaced, were not removed
until CVS 1.6.

* Submitting patches (tactics)
d77 1
a77 5
to the NEWS file and cvs.texinfo, if the change is a user-visible
change worth mentioning.

It is nice to have a test case (see TESTS), especially for fixes which
involve subtle behaviors or twisted sections of the code.
a102 27

* Mailing lists

Anyone can add themselves to the following mailing lists:

    devel-cvs.  Unless you are accepted as a CVS developer as
      described in the DEVEL-CVS file, you will only be able to
      read this list, not send to it.  The charter of the list is
      also in DEVEL-CVS.
    commit-cvs.  The only messages sent to this list are sent
      automatically, via the CVS `loginfo' mechanism, when someone
      checks something in to the master CVS repository.
    test-results.  The only messages sent to this list are sent
      automatically, daily, by a script which runs "make check"
      and "make remotecheck" on the master CVS sources.
To subscribe to devel-cvs, commit-cvs, or test-results, send
a message to "majordomo@@cyclic.com" whose body consists of
"subscribe <list>", where <list> is devel-cvs, commit-cvs or
test-results.

One other list related to CVS development is bug-cvs.  This is the
list which users are requested to send bug reports to.  Anyone can
subscribe; to do so send mail to bug-cvs-request@@prep.ai.mit.edu.

Other CVS discussions take place on the info-cvs mailing list
(send mail to info-cvs-request@@prep.ai.mit.edu to subscribe) or on
the newsgroup comp.software.config-mgmt.
@


1.1.1.1.2.2
log
@Merge cvs from HEAD.
@
text
@a30 6
    switch (c)
    {
	case 'A':
	    aflag = 1;
	    break;
    }
d67 6
a72 7
Do not use arbitrary limits (such as PATH_MAX) except perhaps when the
operating system or some external interface requires it.  We spent a
lot of time getting rid of them, and we don't want to put them back.
If you find any that we missed, please report it as with other bugs.
In most cases such code will create security holes (for example, for
anonymous readonly access via the CVS protocol, or if a WWW cgi script
passes client-supplied arguments to CVS).
d148 1
a148 1
Submit changes to bug-cvs@@gnu.org.
d188 1
a188 1
subscribe; to do so send mail to bug-cvs-request@@gnu.org.
@


1.1.1.2
log
@Import of cvs-1.9.9-970515 onto vendor branch.

Obtained from: cyclic.com
@
text
@d46 5
a50 11
The general rule for portability is that it is only worth including
portability cruft for systems on which people are actually testing and
using new CVS releases.  Without testing, CVS will fail to be portable
for any number of unanticipated reasons.

The current consequence of that general rule seems to be that if it
is in ANSI C and it is in SunOS4 (using /bin/cc), generally it is OK
to use it without ifdefs (for example, assert() and void * as long as
you add more casts to and from void * than ANSI requires.  But not
function prototypes).  Such constructs are generally portable enough,
including to NT, OS/2, VMS, etc.
a60 16
We realize that CVS contains many arbitrary limits (such as PATH_MAX).
Do not do this in new code; we are trying to *fix* those arbitrary
limits.  In particular, it should be possible to pass very long
arguments (e.g. from a WWW cgi script) to CVS without having it
overrun any buffers (which might create a security hole in the WWW
example).

Although this is a long-term goal, it also would be nice to move CVS
in the direction of reentrancy.  This reduces the size of the data
segment and will allow a multi-threaded server if that is desirable.
It is also useful to write the code so that it can be easily be made
reentrant later.  For example, if you need to pass data from a
Parse_Info caller to its callproc, you need a static variable.  But
use a single pointer so that when Parse_Info is fixed to pass along a
void * argument, then the code can easily use that argument.

d68 1
a68 38
Filenames for .c and .h files may contain _ but should not contain -
(the latter causes Visual C++ 2.1 to create makefiles which Visual C++
4.0 cannot use).

* Submitting patches (strategy)

Only some kinds of changes are suitable for inclusion in the
"official" CVS.  Bugfixes, where CVS's behavior contradicts the
documentation and/or expectations that everyone agrees on, should be
OK (strategically).  For features, the desirable attributes are that
the need is clear and that they fit nicely into the architecture of
CVS.

However, if there is reason to think that a change would significantly
inconvenience any significant body of CVS users, or would be
controversial for other reasons, then the design should be re-thought.
Go back to the requirements (writing documentation might help, if you
write the documentation to explain why one would use the feature not
just what the feature does).  Think about whether there is a behavior
which works in both your situation and the other situations.  Make a
list of the issues (for example, submit a comment or documentation
change).  Ask your coworkers, a newsgroup, or a mailing list, and see
what other people think.  Distribute some experimental patches outside
the "official" CVS and see what people think.  By this process, the
intention is that once-controversial changes can be refined to the
point where they are relatively uncontroversial before they are
actually checked in to the "official" CVS.  Features like zlib,
encryption, and others have benefitted from this process in the past
by being mentioned in the documentation and/or discussed, before an
implementation was checked in.

If longstanding CVS behavior, that people may be relying on, is
clearly deficient, it can be changed, but only slowly and carefully.
For example, the global -q option was introduced in CVS 1.3 but the
command -q options, which the global -q replaced, were not removed
until CVS 1.6.

* Submitting patches (tactics)
d77 1
a77 5
to the NEWS file and cvs.texinfo, if the change is a user-visible
change worth mentioning.

It is nice to have a test case (see TESTS), especially for fixes which
involve subtle behaviors or twisted sections of the code.
a102 27

* Mailing lists

Anyone can add themselves to the following mailing lists:

    devel-cvs.  Unless you are accepted as a CVS developer as
      described in the DEVEL-CVS file, you will only be able to
      read this list, not send to it.  The charter of the list is
      also in DEVEL-CVS.
    commit-cvs.  The only messages sent to this list are sent
      automatically, via the CVS `loginfo' mechanism, when someone
      checks something in to the master CVS repository.
    test-results.  The only messages sent to this list are sent
      automatically, daily, by a script which runs "make check"
      and "make remotecheck" on the master CVS sources.
To subscribe to devel-cvs, commit-cvs, or test-results, send
a message to "majordomo@@cyclic.com" whose body consists of
"subscribe <list>", where <list> is devel-cvs, commit-cvs or
test-results.

One other list related to CVS development is bug-cvs.  This is the
list which users are requested to send bug reports to.  Anyone can
subscribe; to do so send mail to bug-cvs-request@@prep.ai.mit.edu.

Other CVS discussions take place on the info-cvs mailing list
(send mail to info-cvs-request@@prep.ai.mit.edu to subscribe) or on
the newsgroup comp.software.config-mgmt.
@


1.1.1.3
log
@Import cvs-1.9.23 as at 19980123.  There are a number of really nice
things fixed in here, including the '-ko' vs. -A problem with
remote cvs which caused all files with -ko to be resent each time
(which is damn painful over a modem, I can tell you).  It also found a
heap of stray empty directories that should have been pruned with the -P
flag to cvs update but were not for some reason.

It also has the fully integrated rcs and diff, so no more fork/exec
overheads for rcs,ci,patch,diff,etc.  This means that it parses the control
data in the rcs files only once rather than twice or more.

If the 'cvs diff' vs. Index thing is going to be fixed for future patch
compatability, this is the place to do it.
@
text
@a30 6
    switch (c)
    {
	case 'A':
	    aflag = 1;
	    break;
    }
d67 6
a72 7
Do not use arbitrary limits (such as PATH_MAX) except perhaps when the
operating system or some external interface requires it.  We spent a
lot of time getting rid of them, and we don't want to put them back.
If you find any that we missed, please report it as with other bugs.
In most cases such code will create security holes (for example, for
anonymous readonly access via the CVS protocol, or if a WWW cgi script
passes client-supplied arguments to CVS).
d148 1
a148 1
Submit changes to bug-cvs@@gnu.org.
d188 1
a188 1
subscribe; to do so send mail to bug-cvs-request@@gnu.org.
@


1.1.1.3.2.1
log
@MFC: cvs 1.10.7, as we run on freefall.

Approved by:	jkh
@
text
@d101 1
a101 1
* Writing patches (strategy)
d108 1
a108 2
CVS.  Is it worth the cost (in terms of complexity or any other
tradeoffs involved)?  Are there better solutions?
d110 17
a126 9
If the design is not yet clear (which is true of most features), then
the design is likely to benefit from more work and community input.
Make a list of issues, or write documentation including rationales for
how one would use the feature.  Discuss it with coworkers, a
newsgroup, or a mailing list, and see what other people think.
Distribute some experimental patches and see what people think.  The
intention is arrive at some kind of rough community consensus before
changing the "official" CVS.  Features like zlib, encryption, and
the RCS library have benefitted from this process in the past.
d134 1
a134 1
* Writing patches (tactics)
d136 29
a164 41
When you first distribute a patch it may be suitable to just put forth
a rough patch, or even just an idea.  But before the end of the
process the following should exist:

  - ChangeLog entry (see the GNU coding standards for details).

  - Changes to the NEWS file and cvs.texinfo, if the change is a
    user-visible change worth mentioning.

  - Somewhere, a description of what the patch fixes (often in
    comments in the code, or maybe the ChangeLog or documentation).

  - Most of the time, a test case (see TESTS).  It can be quite
    frustrating to fix a bug only to see it reappear later, and adding
    the case to the testsuite, where feasible, solves this and other
    problems.

If you solve several unrelated problems, it is generally easier to
consider the desirability of the changes if there is a separate patch
for each issue.  Use context diffs or unidiffs for patches.

Include words like "I grant permission to distribute this patch under
the terms of the GNU Public License" with your patch.  By sending a
patch to bug-cvs@@gnu.org, you implicitly grant this permission.

Submitting a patch to bug-cvs is the way to reach the people who have
signed up to receive such submissions (including CVS developers), but
there may or may not be much (or any) response.  If you want to pursue
the matter further, you are probably best off working with the larger
CVS community.  Distribute your patch as widely as desired (mailing
lists, newsgroups, web sites, whatever).  Write a web page or other
information describing what the patch is for.  It is neither practical
nor desirable for all/most contributions to be distributed through the
"official" (whatever that means) mechanisms of CVS releases and CVS
developers.  Now, the "official" mechanisms do try to incorporate
those patches which seem most suitable for widespread usage, together
with test cases and documentation.  So if a patch becomes sufficiently
popular in the CVS community, it is likely that one of the CVS
developers will eventually try to do something with it.  But dealing
with the CVS developers may be the last step of the process rather
than the first.
d198 1
a198 1
(send mail to info-cvs-request@@gnu.org to subscribe) or on
@


1.1.1.4
log
@Import cvs-1.10.7.  There are a number of nasty bugs that have been fixed.

Obtained from:  cyclic.com
@
text
@d101 1
a101 1
* Writing patches (strategy)
d108 1
a108 2
CVS.  Is it worth the cost (in terms of complexity or any other
tradeoffs involved)?  Are there better solutions?
d110 17
a126 9
If the design is not yet clear (which is true of most features), then
the design is likely to benefit from more work and community input.
Make a list of issues, or write documentation including rationales for
how one would use the feature.  Discuss it with coworkers, a
newsgroup, or a mailing list, and see what other people think.
Distribute some experimental patches and see what people think.  The
intention is arrive at some kind of rough community consensus before
changing the "official" CVS.  Features like zlib, encryption, and
the RCS library have benefitted from this process in the past.
d134 1
a134 1
* Writing patches (tactics)
d136 29
a164 41
When you first distribute a patch it may be suitable to just put forth
a rough patch, or even just an idea.  But before the end of the
process the following should exist:

  - ChangeLog entry (see the GNU coding standards for details).

  - Changes to the NEWS file and cvs.texinfo, if the change is a
    user-visible change worth mentioning.

  - Somewhere, a description of what the patch fixes (often in
    comments in the code, or maybe the ChangeLog or documentation).

  - Most of the time, a test case (see TESTS).  It can be quite
    frustrating to fix a bug only to see it reappear later, and adding
    the case to the testsuite, where feasible, solves this and other
    problems.

If you solve several unrelated problems, it is generally easier to
consider the desirability of the changes if there is a separate patch
for each issue.  Use context diffs or unidiffs for patches.

Include words like "I grant permission to distribute this patch under
the terms of the GNU Public License" with your patch.  By sending a
patch to bug-cvs@@gnu.org, you implicitly grant this permission.

Submitting a patch to bug-cvs is the way to reach the people who have
signed up to receive such submissions (including CVS developers), but
there may or may not be much (or any) response.  If you want to pursue
the matter further, you are probably best off working with the larger
CVS community.  Distribute your patch as widely as desired (mailing
lists, newsgroups, web sites, whatever).  Write a web page or other
information describing what the patch is for.  It is neither practical
nor desirable for all/most contributions to be distributed through the
"official" (whatever that means) mechanisms of CVS releases and CVS
developers.  Now, the "official" mechanisms do try to incorporate
those patches which seem most suitable for widespread usage, together
with test cases and documentation.  So if a patch becomes sufficiently
popular in the CVS community, it is likely that one of the CVS
developers will eventually try to do something with it.  But dealing
with the CVS developers may be the last step of the process rather
than the first.
d198 1
a198 1
(send mail to info-cvs-request@@gnu.org to subscribe) or on
@


1.1.1.4.2.1
log
@MFC: update to `cvs' version 1.11.

Approved by:	peter
@
text
@d194 1
a194 1
a message to "majordomo@@cvshome.org" whose body consists of
@


1.1.1.4.2.2
log
@MFC: cvs-1.11.2, plus client.c rev 1.7 (missing client upload)
@
text
@a2 6
* Source

Patches against the development version of CVS are most likely to be accepted:

	$ cvs -d:pserver:anoncvs@@cvs.cvshome.org/cvsroot co ccvs

d144 1
a144 1
    problems.  See the TESTS file for notes on writing new tests.
d183 1
a183 1
    dev.  Unless you are accepted as a CVS developer as
d187 1
a187 1
    cvs.  The only messages sent to this list are sent
d193 4
a196 4
To subscribe to dev, cvs, or test-results, send
a message to "<list>-subscribe@@ccvs.cvshome.org" or visit
http://ccvs.cvshome.org/servlets/ProjectMailingListList and follow the
instructions there.
@


1.1.1.4.2.3
log
@MFC: upgrade to 1.11.17.

Approved by:	peter
@
text
@a106 19
* Regenerating Build Files

On UNIX, if you wish to change the Build files, you will need Autoconf and
Automake.

Some combinations of Automake and Autoconf versions may break the
CVS build if file timestamps aren't set correctly and people don't
have the same versions the developers do, so the rules to run them
automatically aren't included in the generated Makefiles unless you run
configure with the --enable-maintainer-mode option.

The CVS Makefiles and configure script were built using Automake 1.7.9 and
Autoconf 2.58, respectively.

There is a known bug in Autoconf 2.57 that will prevent the configure
scripts it generates from working on some platforms.  Other combinations of
autotool versions may or may not work.  If you get other versions to work,
please send a report to <bug-cvs@@gnu.org>.

@


1.1.1.5
log
@Import cvs-1.11 onto vendor branch.
@
text
@d194 1
a194 1
a message to "majordomo@@cvshome.org" whose body consists of
@


1.1.1.6
log
@Import cvs-1.11.2 onto vendor branch

Obtained from: http://www.cvshome.org/
@
text
@a2 6
* Source

Patches against the development version of CVS are most likely to be accepted:

	$ cvs -d:pserver:anoncvs@@cvs.cvshome.org/cvsroot co ccvs

d144 1
a144 1
    problems.  See the TESTS file for notes on writing new tests.
d183 1
a183 1
    dev.  Unless you are accepted as a CVS developer as
d187 1
a187 1
    cvs.  The only messages sent to this list are sent
d193 4
a196 4
To subscribe to dev, cvs, or test-results, send
a message to "<list>-subscribe@@ccvs.cvshome.org" or visit
http://ccvs.cvshome.org/servlets/ProjectMailingListList and follow the
instructions there.
@


1.1.1.7
log
@Import cvs-1.11.17 onto vendor branch.
@
text
@a106 19
* Regenerating Build Files

On UNIX, if you wish to change the Build files, you will need Autoconf and
Automake.

Some combinations of Automake and Autoconf versions may break the
CVS build if file timestamps aren't set correctly and people don't
have the same versions the developers do, so the rules to run them
automatically aren't included in the generated Makefiles unless you run
configure with the --enable-maintainer-mode option.

The CVS Makefiles and configure script were built using Automake 1.7.9 and
Autoconf 2.58, respectively.

There is a known bug in Autoconf 2.57 that will prevent the configure
scripts it generates from working on some platforms.  Other combinations of
autotool versions may or may not work.  If you get other versions to work,
please send a report to <bug-cvs@@gnu.org>.

@


1.1.1.7.18.1
log
@SVN rev 180918 on 2008-07-28 16:52:28Z by obrien

MFC: CVS version 1.11.22.1 (almost 1.11.23).
@
text
@a2 19
* License of CVS

    CVS is Copyright (C) 1986-2006 The Free Software Foundation, Inc.

    This program is free software; you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation; either version 1, or (at your option)
    any later version.

    More details are available in the COPYING file but, in simplified
    terms, this means that any distributed modifications you make to
    this software must also be released under the GNU General Public
    License.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

d7 1
a7 4
	$ cvs -z3 -d:pserver:anonymous@@cvs.sv.nongnu.org:/sources/cvs co ccvs

See the Savannah sources page <http://savannah.nongnu.org/cvs/?group=cvs> for
more information.
d16 1
a16 1
    $ CFLAGS="-g -Wall" ./configure
d22 1
a22 16
    $ CFLAGS="-g -Wall" ./config.status --recheck

* Backwards Compatibility

Only bug fixes are accepted into the stable branch.  New features should be
applied to the trunk.

If it is not inextricable from a bug fix, CVS's output (to stdout/stderr)
should not be changed on the stable branch in order to best support scripts and
other tools which parse CVS's output.  It is ok to change output between
feature releases (on the trunk), though such changes should be noted in the
NEWS file.

Changes in the way CVS responds to command line options, config options, etc.
should be accompanied by deprecation warnings for an entire stable series of
releases before being changed permanently, if at all possible.
d103 4
d118 2
a119 2
The CVS Makefiles and configure script were built using Automake 1.10 and
Autoconf 2.61, respectively.
d124 1
a124 1
please send a report to <bug-cvs@@nongnu.org>.
d177 1
a177 1
patch to bug-cvs@@nongnu.org, you implicitly grant this permission.
d206 1
a206 2
In addition to the mailing lists listed in the README file, developers should
take particular note of the following mailling lists:
d208 5
a212 6
    bug-cvs:  This is the list which users are requested to send bug reports
      to.  General CVS development and design discussions also take place on
      this list.
    info-cvs:  This list is intended for user questions, but general CVS
      development and design discussions sometimes take place on this list.
    cvs-cvs:  The only messages sent to this list are sent
d215 1
a215 1
    cvs-test-results:  The only messages sent to this list are sent
d218 12
a229 4

To subscribe to any of these lists, send mail to <list>-request@@nongnu.org
or visit http://savannah.nongnu.org/mail/?group=cvs and follow the instructions
for the list you wish to subscribe to.
@


1.1.1.8
log
@Import cvs-1.11.22 onto vendor branch.
@
text
@a2 19
* License of CVS

    CVS is Copyright (C) 1989-2005 The Free Software Foundation, Inc.

    This program is free software; you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation; either version 1, or (at your option)
    any later version.

    More details are available in the COPYING file but, in simplified
    terms, this means that any distributed modifications you make to
    this software must also be released under the GNU General Public
    License.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

d7 1
a7 1
    $ CVS_RSH=ssh cvs -d:ext:anoncvs@@savannah.nongnu.org:/cvsroot/cvs co ccvs
d16 1
a16 1
    $ CFLAGS="-g -Wall" ./configure
d22 1
a22 16
    $ CFLAGS="-g -Wall" ./config.status --recheck

* Backwards Compatibility

Only bug fixes are accepted into the stable branch.  New features should be
applied to the trunk.

If it is not inextricable from a bug fix, CVS's output (to stdout/stderr)
should not be changed on the stable branch in order to best support scripts and
other tools which parse CVS's output.  It is ok to change output between
feature releases (on the trunk), though such changes should be noted in the
NEWS file.

Changes in the way CVS responds to command line options, config options, etc.
should be accompanied by deprecation warnings for an entire stable series of
releases before being changed permanently, if at all possible.
d103 4
d118 2
a119 2
The CVS Makefiles and configure script were built using Automake 1.9.6 and
Autoconf 2.59, respectively.
d124 1
a124 1
please send a report to <bug-cvs@@nongnu.org>.
d177 1
a177 1
patch to bug-cvs@@nongnu.org, you implicitly grant this permission.
d206 1
a206 2
In addition to the mailing lists listed in the README file, developers should
take particular note of the following mailling lists:
d208 5
a212 6
    bug-cvs:  This is the list which users are requested to send bug reports
      to.  General CVS development and design discussions also take place on
      this list.
    info-cvs:  This list is intended for user questions, but general CVS
      development and design discussions sometimes take place on this list.
    cvs-cvs:  The only messages sent to this list are sent
d215 1
a215 1
    cvs-test-results:  The only messages sent to this list are sent
d218 12
a229 4

To subscribe to any of these lists, send mail to <list>-request@@nongnu.org
or visit http://savannah.nongnu.org/mail/?group=cvs and follow the instructions
for the list you wish to subscribe to.
@


1.1.1.9
log
@Import of 1.11 branch snapshot - using the 10-March-2008 code base.
@
text
@d5 1
a5 1
    CVS is Copyright (C) 1986-2006 The Free Software Foundation, Inc.
d26 1
a26 4
	$ cvs -z3 -d:pserver:anonymous@@cvs.sv.nongnu.org:/sources/cvs co ccvs

See the Savannah sources page <http://savannah.nongnu.org/cvs/?group=cvs> for
more information.
d148 2
a149 2
The CVS Makefiles and configure script were built using Automake 1.10 and
Autoconf 2.61, respectively.
@


1.1.1.9.18.1
log
@file HACKING was added on branch RELENG_8_4 on 2013-03-28 13:00:40 +0000
@
text
@d1 256
@


1.1.1.9.18.2
log
@## SVN ## Exported commit - http://svnweb.freebsd.org/changeset/base/248810
## SVN ## CVS IS DEPRECATED: http://wiki.freebsd.org/CvsIsDeprecated
@
text
@a0 256
How to write code for CVS

* License of CVS

    CVS is Copyright (C) 1986-2006 The Free Software Foundation, Inc.

    This program is free software; you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation; either version 1, or (at your option)
    any later version.

    More details are available in the COPYING file but, in simplified
    terms, this means that any distributed modifications you make to
    this software must also be released under the GNU General Public
    License.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

* Source

Patches against the development version of CVS are most likely to be accepted:

	$ cvs -z3 -d:pserver:anonymous@@cvs.sv.nongnu.org:/sources/cvs co ccvs

See the Savannah sources page <http://savannah.nongnu.org/cvs/?group=cvs> for
more information.

* Compiler options

If you are using GCC, you'll want to configure with -Wall, which can
detect many programming errors.  This is not the default because it
might cause spurious warnings, but at least on some machines, there
should be no spurious warnings.  For example:

    $ CFLAGS="-g -Wall" ./configure

Configure is not very good at remembering this setting; it will get
wiped out whenever you do a ./config.status --recheck, so you'll need
to use:

    $ CFLAGS="-g -Wall" ./config.status --recheck

* Backwards Compatibility

Only bug fixes are accepted into the stable branch.  New features should be
applied to the trunk.

If it is not inextricable from a bug fix, CVS's output (to stdout/stderr)
should not be changed on the stable branch in order to best support scripts and
other tools which parse CVS's output.  It is ok to change output between
feature releases (on the trunk), though such changes should be noted in the
NEWS file.

Changes in the way CVS responds to command line options, config options, etc.
should be accompanied by deprecation warnings for an entire stable series of
releases before being changed permanently, if at all possible.

* Indentation style

CVS mostly uses a consistent indentation style which looks like this:

void
foo (arg)
    char *arg;
{
    if (arg != NULL)
    {
	bar (arg);
	baz (arg);
    }
    switch (c)
    {
	case 'A':
	    aflag = 1;
	    break;
    }
}

The file cvs-format.el contains settings for emacs and the NEWS file
contains a set of options for the indent program which I haven't tried
but which are correct as far as I know.  You will find some code which
does not conform to this indentation style; the plan is to reindent it
as those sections of the code are changed (one function at a time,
perhaps).

In a submitted patch it is acceptable to refrain from changing the
indentation of large blocks of code to minimize the size of the patch;
the person checking in such a patch should reindent it.

* Portability

The general rule for portability is that it is only worth including
portability cruft for systems on which people are actually testing and
using new CVS releases.  Without testing, CVS will fail to be portable
for any number of unanticipated reasons.

The current consequence of that general rule seems to be that if it
is in ANSI C and it is in SunOS4 (using /bin/cc), generally it is OK
to use it without ifdefs (for example, assert() and void * as long as
you add more casts to and from void * than ANSI requires.  But not
function prototypes).  Such constructs are generally portable enough,
including to NT, OS/2, VMS, etc.

* Run-time behaviors

Use assert() to check "can't happen" conditions internal to CVS.  We
realize that there are functions in CVS which instead return NULL or
some such value (thus confusing the meaning of such a returned value),
but we want to fix that code.  Of course, bad input data, a corrupt
repository, bad options, etc., should always print a real error
message instead.

Do not use arbitrary limits (such as PATH_MAX) except perhaps when the
operating system or some external interface requires it.  We spent a
lot of time getting rid of them, and we don't want to put them back.
If you find any that we missed, please report it as with other bugs.
In most cases such code will create security holes (for example, for
anonymous readonly access via the CVS protocol, or if a WWW cgi script
passes client-supplied arguments to CVS).

Although this is a long-term goal, it also would be nice to move CVS
in the direction of reentrancy.  This reduces the size of the data
segment and will allow a multi-threaded server if that is desirable.
It is also useful to write the code so that it can be easily be made
reentrant later.  For example, if you need to pass data from a
Parse_Info caller to its callproc, you need a static variable.  But
use a single pointer so that when Parse_Info is fixed to pass along a
void * argument, then the code can easily use that argument.

* Coding standards in general

Generally speaking the GNU coding standards are mostly used by CVS
(but see the exceptions mentioned above, such as indentation style,
and perhaps an exception or two we haven't mentioned).  This is the
file standards.text at the GNU FTP sites.

* Regenerating Build Files

On UNIX, if you wish to change the Build files, you will need Autoconf and
Automake.

Some combinations of Automake and Autoconf versions may break the
CVS build if file timestamps aren't set correctly and people don't
have the same versions the developers do, so the rules to run them
automatically aren't included in the generated Makefiles unless you run
configure with the --enable-maintainer-mode option.

The CVS Makefiles and configure script were built using Automake 1.10 and
Autoconf 2.61, respectively.

There is a known bug in Autoconf 2.57 that will prevent the configure
scripts it generates from working on some platforms.  Other combinations of
autotool versions may or may not work.  If you get other versions to work,
please send a report to <bug-cvs@@nongnu.org>.

* Writing patches (strategy)

Only some kinds of changes are suitable for inclusion in the
"official" CVS.  Bugfixes, where CVS's behavior contradicts the
documentation and/or expectations that everyone agrees on, should be
OK (strategically).  For features, the desirable attributes are that
the need is clear and that they fit nicely into the architecture of
CVS.  Is it worth the cost (in terms of complexity or any other
tradeoffs involved)?  Are there better solutions?

If the design is not yet clear (which is true of most features), then
the design is likely to benefit from more work and community input.
Make a list of issues, or write documentation including rationales for
how one would use the feature.  Discuss it with coworkers, a
newsgroup, or a mailing list, and see what other people think.
Distribute some experimental patches and see what people think.  The
intention is arrive at some kind of rough community consensus before
changing the "official" CVS.  Features like zlib, encryption, and
the RCS library have benefitted from this process in the past.

If longstanding CVS behavior, that people may be relying on, is
clearly deficient, it can be changed, but only slowly and carefully.
For example, the global -q option was introduced in CVS 1.3 but the
command -q options, which the global -q replaced, were not removed
until CVS 1.6.

* Writing patches (tactics)

When you first distribute a patch it may be suitable to just put forth
a rough patch, or even just an idea.  But before the end of the
process the following should exist:

  - ChangeLog entry (see the GNU coding standards for details).

  - Changes to the NEWS file and cvs.texinfo, if the change is a
    user-visible change worth mentioning.

  - Somewhere, a description of what the patch fixes (often in
    comments in the code, or maybe the ChangeLog or documentation).

  - Most of the time, a test case (see TESTS).  It can be quite
    frustrating to fix a bug only to see it reappear later, and adding
    the case to the testsuite, where feasible, solves this and other
    problems.  See the TESTS file for notes on writing new tests.

If you solve several unrelated problems, it is generally easier to
consider the desirability of the changes if there is a separate patch
for each issue.  Use context diffs or unidiffs for patches.

Include words like "I grant permission to distribute this patch under
the terms of the GNU Public License" with your patch.  By sending a
patch to bug-cvs@@nongnu.org, you implicitly grant this permission.

Submitting a patch to bug-cvs is the way to reach the people who have
signed up to receive such submissions (including CVS developers), but
there may or may not be much (or any) response.  If you want to pursue
the matter further, you are probably best off working with the larger
CVS community.  Distribute your patch as widely as desired (mailing
lists, newsgroups, web sites, whatever).  Write a web page or other
information describing what the patch is for.  It is neither practical
nor desirable for all/most contributions to be distributed through the
"official" (whatever that means) mechanisms of CVS releases and CVS
developers.  Now, the "official" mechanisms do try to incorporate
those patches which seem most suitable for widespread usage, together
with test cases and documentation.  So if a patch becomes sufficiently
popular in the CVS community, it is likely that one of the CVS
developers will eventually try to do something with it.  But dealing
with the CVS developers may be the last step of the process rather
than the first.

* What is the schedule for the next release?

There isn't one.  That is, upcoming releases are not announced (or
even hinted at, really) until the feature freeze which is
approximately 2 weeks before the final release (at this time test
releases start appearing and are announced on info-cvs).  This is
intentional, to avoid a last minute rush to get new features in.

* Mailing lists

In addition to the mailing lists listed in the README file, developers should
take particular note of the following mailling lists:

    bug-cvs:  This is the list which users are requested to send bug reports
      to.  General CVS development and design discussions also take place on
      this list.
    info-cvs:  This list is intended for user questions, but general CVS
      development and design discussions sometimes take place on this list.
    cvs-cvs:  The only messages sent to this list are sent
      automatically, via the CVS `loginfo' mechanism, when someone
      checks something in to the master CVS repository.
    cvs-test-results:  The only messages sent to this list are sent
      automatically, daily, by a script which runs "make check"
      and "make remotecheck" on the master CVS sources.

To subscribe to any of these lists, send mail to <list>-request@@nongnu.org
or visit http://savannah.nongnu.org/mail/?group=cvs and follow the instructions
for the list you wish to subscribe to.
@


