Import of slightly trimmed cvs-1.8 distribution. Generated files

and non-unix code has been left out.

1 files changed, 102 insertions, 0 deletions

diff --git a/contrib/cvs/HACKING b/contrib/cvs/HACKING
new file mode 100644
index 0000000..ac4cdd1
--- /dev/null
+++ b/contrib/cvs/HACKING
@@ -0,0 +1,102 @@
+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.