1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
5 >The CVS Repository</TITLE
8 CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
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"
77 >2. The CVS Repository</A
80 > If you become part of the active development team, you will eventually
81 need write access to our holy grail, the CVS repository. One of the
82 team members will need to set this up for you. Please read
83 this chapter completely before accessing via CVS.
91 >2.1. Access to CVS</A
94 > The project's CVS repository is hosted on
96 HREF="http://sourceforge.net/"
100 Please refer to the chapters 6 and 7 in
102 HREF="http://sourceforge.net/docman/?group_id=1"
106 > for the technical access details for your
107 operating system. For historical reasons, the CVS server is
110 >cvs.ijbswa.sourceforge.net</VAR
115 >, and the source tree module is called
131 > Within the CVS repository, there are modules and branches. As
132 mentioned, the sources are in the <VAR
139 >. Other modules are present for platform specific
140 issues. There is a webview of the CVS hierarchy at <A
141 HREF="http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ijbswa/"
143 >http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ijbswa/</A
145 which might help with visualizing how these pieces fit together.
148 > Branches are used to fork a sub-development path from the main trunk.
152 > module where the sources are, there
153 is always at least one <SPAN
156 > from the main trunk
157 devoted to a stable release series. The main trunk is where active
158 development takes place for the next stable series (e.g. 3.2.x).
159 So just prior to each stable series (e.g. 3.0.x), a branch is created
160 just for stable series releases (e.g. 3.0.0 -> 3.0.1 -> 3.0.2, etc).
161 Once the initial stable release of any stable branch has taken place,
166 >only used for bugfixes</I
169 had prior testing before being committed to CVS. (See <A
170 HREF="newrelease.html#VERSIONNUMBERS"
172 > below for details on
176 > This will result in at least two active branches, which means there may
177 be occasions that require the same (or similar) item to be
178 checked into to two different places (assuming its a bugfix and needs
179 fixing in both the stable and unstable trees). This also means that in
180 order to have access to both trees, both will have to be checked out
181 separately. Use the <VAR
184 > flag to check out a
187 >cvs co -r v_3_0_branch current</VAR
197 >2.3. CVS Commit Guidelines</A
200 > The source tree is the heart of every software project. Every effort must
201 be made to ensure that it is readable, compilable and consistent at all
202 times. There are differing guidelines for the stable branch and the
203 main development trunk, and we ask anyone with CVS access to strictly
204 adhere to the following guidelines:
207 > Basic Guidelines, for all branches:
221 >) be tempted to commit
222 that small change without testing it thoroughly first. When we're
223 close to a public release, ask a fellow developer to review your
229 > Your commit message should give a concise overview of <SPAN
236 > (no big details) and <SPAN
240 >why you changed it</I
243 Just check previous messages for good examples.
248 > Don't use the same message on multiple files, unless it equally applies to
254 > If your changes span multiple files, and the code won't recompile unless
255 all changes are committed (e.g. when changing the signature of a function),
256 then commit all files one after another, without long delays in between.
257 If necessary, prepare the commit messages in advance.
262 > Before changing things on CVS, make sure that your changes are in line
263 with the team's general consensus on what should be done.
268 > Note that near a major public release, we get more cautious.
269 There is always the possibility to submit a patch to the <A
270 HREF="http://sourceforge.net/tracker/?atid=311118&group_id=11118&func=browse"
281 > Stable branches are handled with more care, especially after the
282 initial *.*.0 release, and we are just in bugfix mode. In addition to
283 the above, the below applies only to the stable branch (currently the
295 > Do not commit <SPAN
301 > unless your proposed
302 changes have been well tested first, preferably by other members of the
303 project, or have prior approval of the project leaders or consensus
309 > Where possible, bugfixes and changes should be tested in the main
310 development trunk first. There may be occasions where this is not
316 > Alternately, proposed changes can be submitted as patches to the patch tracker on
317 Sourceforge first: <A
318 HREF="http://sourceforge.net/tracker/?group_id=11118&atid=311118"
320 >http://sourceforge.net/tracker/?group_id=11118&atid=311118</A
322 Then ask for peer review.
327 > Do not even think about anything except bugfixes. No new features!
340 SUMMARY="Footer navigation table"
351 HREF="introduction.html"
369 HREF="documentation.html"
389 >Documentation Guidelines</TD