+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
->Version Control Guidelines</TITLE
+>The CVS Repository</TITLE
><META
NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.64
-"><LINK
+CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
REL="HOME"
TITLE="Privoxy Developer Manual"
HREF="index.html"><LINK
REL="PREVIOUS"
-TITLE="Coding Guidelines"
-HREF="coding.html"><LINK
+TITLE="Introduction"
+HREF="introduction.html"><LINK
REL="NEXT"
-TITLE="Testing Guidelines"
-HREF="testing.html"><LINK
+TITLE="Documentation Guidelines"
+HREF="documentation.html"><LINK
REL="STYLESHEET"
TYPE="text/css"
HREF="../p_doc.css"></HEAD
><DIV
CLASS="NAVHEADER"
><TABLE
+SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
ALIGN="left"
VALIGN="bottom"
><A
-HREF="coding.html"
+HREF="introduction.html"
+ACCESSKEY="P"
>Prev</A
></TD
><TD
ALIGN="right"
VALIGN="bottom"
><A
-HREF="testing.html"
+HREF="documentation.html"
+ACCESSKEY="N"
>Next</A
></TD
></TR
CLASS="SECT1"
><A
NAME="CVS"
->6. Version Control Guidelines</A
+>2. The CVS Repository</A
></H1
><P
->To be filled. note on cvs comments. Don't only comment what you did,
- but also why you did it!</P
+> If you become part of the active development team, you will eventually
+ need write access to our holy grail, the CVS repository. One of the
+ team members will need to set this up for you. Please read
+ this chapter completely before accessing via CVS.
+ </P
+><DIV
+CLASS="SECT2"
+><H2
+CLASS="SECT2"
+><A
+NAME="CVSACCESS"
+>2.1. Access to CVS</A
+></H2
+><P
+> The project's CVS repository is hosted on
+ <A
+HREF="http://sourceforge.net/"
+TARGET="_top"
+>SourceForge.</A
+>
+ Please refer to the chapters 6 and 7 in
+ <A
+HREF="http://sourceforge.net/docman/?group_id=1"
+TARGET="_top"
+>SF's site
+ documentation</A
+> for the technical access details for your
+ operating system. For historical reasons, the CVS server is
+ called <VAR
+CLASS="LITERAL"
+>cvs.ijbswa.sourceforge.net</VAR
+>, the repository is
+ called <VAR
+CLASS="LITERAL"
+>ijbswa</VAR
+>, and the source tree module is called
+ <VAR
+CLASS="LITERAL"
+>current</VAR
+>.
+ </P
+></DIV
+><DIV
+CLASS="SECT2"
+><H2
+CLASS="SECT2"
+><A
+NAME="CVSBRANCHES"
+>2.2. Branches</A
+></H2
+><P
+> Within the CVS repository, there are modules and branches. As
+ mentioned, the sources are in the <VAR
+CLASS="LITERAL"
+>current</VAR
+>
+ <SPAN
+CLASS="QUOTE"
+>"module"</SPAN
+>. Other modules are present for platform specific
+ issues. There is a webview of the CVS hierarchy at <A
+HREF="http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ijbswa/"
+TARGET="_top"
+>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ijbswa/</A
+>,
+ which might help with visualizing how these pieces fit together.
+ </P
+><P
+> Branches are used to fork a sub-development path from the main trunk.
+ Within the <VAR
+CLASS="LITERAL"
+>current</VAR
+> module where the sources are, there
+ is always at least one <SPAN
+CLASS="QUOTE"
+>"branch"</SPAN
+> from the main trunk
+ devoted to a stable release series. The main trunk is where active
+ development takes place for the next stable series (e.g. 3.2.x).
+ So just prior to each stable series (e.g. 3.0.x), a branch is created
+ just for stable series releases (e.g. 3.0.0 -> 3.0.1 -> 3.0.2, etc).
+ Once the initial stable release of any stable branch has taken place,
+ this branch is <SPAN
+CLASS="emphasis"
+><I
+CLASS="EMPHASIS"
+>only used for bugfixes</I
+></SPAN
+>, which have
+ had prior testing before being committed to CVS. (See <A
+HREF="newrelease.html#VERSIONNUMBERS"
+>Version Numbers</A
+> below for details on
+ versioning.)
+ </P
+><P
+> This will result in at least two active branches, which means there may
+ be occasions that require the same (or similar) item to be
+ checked into to two different places (assuming its a bugfix and needs
+ fixing in both the stable and unstable trees). This also means that in
+ order to have access to both trees, both will have to be checked out
+ separately. Use the <VAR
+CLASS="LITERAL"
+>cvs -r</VAR
+> flag to check out a
+ branch, e.g: <VAR
+CLASS="LITERAL"
+>cvs co -r v_3_0_branch current</VAR
+>.
+ </P
+></DIV
+><DIV
+CLASS="SECT2"
+><H2
+CLASS="SECT2"
+><A
+NAME="CVSCOMMIT"
+>2.3. CVS Commit Guidelines</A
+></H2
+><P
+> The source tree is the heart of every software project. Every effort must
+ be made to ensure that it is readable, compilable and consistent at all
+ times. There are differing guidelines for the stable branch and the
+ main development trunk, and we ask anyone with CVS access to strictly
+ adhere to the following guidelines:
+ </P
+><P
+> Basic Guidelines, for all branches:
+ </P
+><P
+> <P
+></P
+><UL
+><LI
+><P
+> Never (read: <SPAN
+CLASS="emphasis"
+><I
+CLASS="EMPHASIS"
+>never, ever</I
+></SPAN
+>) be tempted to commit
+ that small change without testing it thoroughly first. When we're
+ close to a public release, ask a fellow developer to review your
+ changes.
+ </P
+></LI
+><LI
+><P
+> Your commit message should give a concise overview of <SPAN
+CLASS="emphasis"
+><I
+CLASS="EMPHASIS"
+>what you
+ changed</I
+></SPAN
+> (no big details) and <SPAN
+CLASS="emphasis"
+><I
+CLASS="EMPHASIS"
+>why you changed it</I
+></SPAN
+>
+ Just check previous messages for good examples.
+ </P
+></LI
+><LI
+><P
+> Don't use the same message on multiple files, unless it equally applies to
+ all those files.
+ </P
+></LI
+><LI
+><P
+> If your changes span multiple files, and the code won't recompile unless
+ all changes are committed (e.g. when changing the signature of a function),
+ then commit all files one after another, without long delays in between.
+ If necessary, prepare the commit messages in advance.
+ </P
+></LI
+><LI
+><P
+> Before changing things on CVS, make sure that your changes are in line
+ with the team's general consensus on what should be done.
+ </P
+></LI
+><LI
+><P
+> Note that near a major public release, we get more cautious.
+ There is always the possibility to submit a patch to the <A
+HREF="http://sourceforge.net/tracker/?atid=311118&group_id=11118&func=browse"
+TARGET="_top"
+>patch
+ tracker</A
+> instead.
+ </P
+></LI
+></UL
+>
+ </P
+><P
+> Stable branches are handled with more care, especially after the
+ initial *.*.0 release, and we are just in bugfix mode. In addition to
+ the above, the below applies only to the stable branch (currently the
+ <VAR
+CLASS="LITERAL"
+>v_3_0_branch</VAR
+> branch):
+ </P
+><P
+> <P
+></P
+><UL
+><LI
+><P
+> Do not commit <SPAN
+CLASS="emphasis"
+><I
+CLASS="EMPHASIS"
+>anything</I
+></SPAN
+> unless your proposed
+ changes have been well tested first, preferably by other members of the
+ project, or have prior approval of the project leaders or consensus
+ of the devel list.
+ </P
+></LI
+><LI
+><P
+> Where possible, bugfixes and changes should be tested in the main
+ development trunk first. There may be occasions where this is not
+ feasible, though.
+ </P
+></LI
+><LI
+><P
+> Alternately, proposed changes can be submitted as patches to the patch tracker on
+ Sourceforge first: <A
+HREF="http://sourceforge.net/tracker/?group_id=11118&atid=311118"
+TARGET="_top"
+>http://sourceforge.net/tracker/?group_id=11118&atid=311118</A
+>.
+ Then ask for peer review.
+ </P
+></LI
+><LI
+><P
+> Do not even think about anything except bugfixes. No new features!
+ </P
+></LI
+></UL
+>
+ </P
+></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
+SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
ALIGN="left"
VALIGN="top"
><A
-HREF="coding.html"
+HREF="introduction.html"
+ACCESSKEY="P"
>Prev</A
></TD
><TD
VALIGN="top"
><A
HREF="index.html"
+ACCESSKEY="H"
>Home</A
></TD
><TD
ALIGN="right"
VALIGN="top"
><A
-HREF="testing.html"
+HREF="documentation.html"
+ACCESSKEY="N"
>Next</A
></TD
></TR
WIDTH="33%"
ALIGN="left"
VALIGN="top"
->Coding Guidelines</TD
+>Introduction</TD
><TD
WIDTH="34%"
ALIGN="center"
WIDTH="33%"
ALIGN="right"
VALIGN="top"
->Testing Guidelines</TD
+>Documentation Guidelines</TD
></TR
></TABLE
></DIV
projects / privoxy.git / blobdiff