4 >The CVS Repository</TITLE
7 CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
10 TITLE="Privoxy Developer Manual"
11 HREF="index.html"><LINK
14 HREF="introduction.html"><LINK
16 TITLE="Documentation Guidelines"
17 HREF="documentation.html"><LINK
20 HREF="../p_doc.css"></HEAD
31 SUMMARY="Header navigation table"
40 >Privoxy Developer Manual</TH
48 HREF="introduction.html"
62 HREF="documentation.html"
76 NAME="CVS">2. The CVS Repository</H1
78 > If you intend to help us with programming, documentation or packaging
79 you will need write access to our holy grail, the CVS repository.
80 Please read this chapter completely before accessing via CVS.
87 NAME="CVSACCESS">2.1. Access to CVS</H2
89 > The project's CVS repository is hosted on
91 HREF="http://sourceforge.net/"
95 Please refer to the chapters 6 and 7 in
97 HREF="http://sourceforge.net/docman/?group_id=1"
101 > for the technical access details for your
102 operating system. For historical reasons, the CVS server is
105 >cvs.ijbswa.sourceforge.net</TT
110 >, and the source tree module is called
122 NAME="CVSBRANCHES">2.2. Branches</H2
124 > Within the CVS repository, there are modules and branches. As
125 mentioned, the sources are in the <TT
132 >. Other modules are present for platform specific
133 issues. There is a webview of the CVS hierarchy at <A
134 HREF="http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ijbswa/"
136 >http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ijbswa/</A
138 which might help with visualizing how these pieces fit together.
141 > Branches are used to fork a sub-development path from the main trunk.
145 > module where the sources are, there
146 is always at least one <SPAN
149 > from the main trunk
150 devoted to a stable release series. The main trunk is where active
151 development takes place for the next stable series (e.g. 3.2.x).
152 And for testing bugfixes for the stable series. Just prior to each
153 stable series (e.g. 3.0.x), a branch is created just for stable series
154 releases (e.g. 3.0.0 -> 3.0.1 -> 3.0.2, etc). Once the initial stable
155 release of any stable branch has taken place, this branch is
160 >only used for bugfixes</I
162 >, which have had prior
163 testing before being committed to CVS. (See <A
164 HREF="newrelease.html#VERSIONNUMBERS"
166 > below for details on
175 NAME="CVSCOMMIT">2.3. CVS Commit Guidelines</H2
177 > The source tree is the heart of every software project. Every effort must
178 be made to ensure that it is readable, compilable and consistent at all
179 times. There are differing guidelines for the stable branch and the
180 main development trunk, and we ask anyone with CVS access to strictly
181 adhere to the following guidelines:
184 > Basic Guidelines, for all branches:
198 >) be tempted to commit
199 that small change without testing it thoroughly first. When we're
200 close to a public release, ask a fellow developer to review your
206 > Your commit message should give a concise overview of <SPAN
213 > (no big details) and <SPAN
217 >why you changed it</I
220 Just check previous messages for good examples.
225 > Don't use the same message on multiple files, unless it equally applies to
231 > If your changes span multiple files, and the code won't recompile unless
232 all changes are committed (e.g. when changing the signature of a function),
233 then commit all files one after another, without long delays in between.
234 If necessary, prepare the commit messages in advance.
239 > Before changing things on CVS, make sure that your changes are in line
240 with the team's general consensus on what should be done.
245 > Note that near a major public release, we get more cautious.
246 There is always the possibility to submit a patch to the <A
247 HREF="http://sourceforge.net/tracker/?atid=311118&group_id=11118&func=browse"
258 > Stable branches are handled with decidedly more care, especially after
259 the initial *.*.0 release, and we are just in bugfix mode. In addition
260 to the above, the below applies only to the stable branch (currently
261 the v_3_0_branchpoint branch):
273 >not commit anything</I
275 > into the stable branch,
276 unless immediately before a new release! There needs to be testing
277 done before it hits CVS, and to ensure that all changes are
278 appropriate just to fix whatever the problem is.
283 > Where possible, bugfixes and changes should be tested in the main
284 development trunk first. There may be occasions where this is not
290 > Alternately, proposed changes can be submitted as patches to the patch tracker on
291 Sourceforge first: <A
292 HREF="http://sourceforge.net/tracker/?group_id=11118&atid=311118"
294 >http://sourceforge.net/tracker/?group_id=11118&atid=311118</A
296 Then ask for peer review.
301 > Do not commit <SPAN
307 > unless your proposed
308 changes have been well tested first, by other members of the
309 project, and have prior approval of the project leaders or consensus
315 > Do not even think about anything except bugfixes. No new features!
328 SUMMARY="Footer navigation table"
339 HREF="introduction.html"
357 HREF="documentation.html"
377 >Documentation Guidelines</TD