1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
|
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
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.
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.
* 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.
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
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 and cvs.texinfo in the case of a user-visible change.
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.
|
