+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>The CVS Repository</TITLE
><META
NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
-"><LINK
+CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REL="HOME"
TITLE="Privoxy Developer Manual"
HREF="index.html"><LINK
HREF="documentation.html"><LINK
REL="STYLESHEET"
TYPE="text/css"
-HREF="../p_doc.css"></HEAD
+HREF="../p_doc.css"><META
+HTTP-EQUIV="Content-Type"
+CONTENT="text/html;
+charset=ISO-8859-1"></HEAD
><BODY
CLASS="SECT1"
BGCOLOR="#EEEEEE"
><H1
CLASS="SECT1"
><A
-NAME="CVS">2. The CVS Repository</H1
+NAME="CVS"
+>2. The CVS Repository</A
+></H1
><P
-> If you intend to help us with programming, documentation or packaging
- you will need write access to our holy grail, the CVS repository.
- Please read this chapter completely before accessing via CVS.
+> 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</H2
+NAME="CVSACCESS"
+>2.1. Access to CVS</A
+></H2
><P
> The project's CVS repository is hosted on
<A
operating system. For historical reasons, the CVS server is
called <TT
CLASS="LITERAL"
->cvs.ijbswa.sourceforge.net</TT
+>ijbswa.cvs.sourceforge.net</TT
>, the repository is
called <TT
CLASS="LITERAL"
><H2
CLASS="SECT2"
><A
-NAME="CVSBRANCHES">2.2. Branches</H2
+NAME="CVSBRANCHES"
+>2.2. Branches</A
+></H2
><P
> Within the CVS repository, there are modules and branches. As
mentioned, the sources are in the <TT
>"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/"
+HREF="http://ijbswa.cvs.sourceforge.net/ijbswa/"
TARGET="_top"
->http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ijbswa/</A
+>http://ijbswa.cvs.sourceforge.net/ijbswa/</A
>,
which might help with visualizing how these pieces fit together.
</P
> 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).
- And for testing bugfixes for the stable series. 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
+ 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
+>, 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
+> At one time there were two distinct branches: stable and unstable. The
+ more drastic changes were to be in the unstable branch. These branches
+ have now been merged to minimize time and effort of maintaining two
+ branches.
+ </P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
-NAME="CVSCOMMIT">2.3. CVS Commit Guidelines</H2
+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
><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
+> Please don't commit even
+ a small change without testing it thoroughly first. When we're
close to a public release, ask a fellow developer to review your
changes.
</P
><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"
+HREF="http://sourceforge.net/tracker/?atid=311118&group_id=11118&func=browse"
TARGET="_top"
>patch
tracker</A
</P
></LI
></UL
->
- </P
-><P
-> Stable branches are handled with decidedly 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 v_3_0_branchpoint branch):
- </P
-><P
-> <P
-></P
-><UL
-><LI
-><P
-> Do <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->not commit anything</I
-></SPAN
-> into the stable branch,
- unless immediately before a new release! There needs to be testing
- done before it hits CVS, and to ensure that all changes are
- appropriate just to fix whatever the problem is.
- </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 commit <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->anything</I
-></SPAN
-> unless your proposed
- changes have been well tested first, by other members of the
- project, and have prior approval of the project leaders or consensus
- of the devel list.
- </P
-></LI
-><LI
-><P
-> Do not even think about anything except bugfixes. No new features!
- </P
-></LI
-></UL
>
</P
></DIV
projects / privoxy.git / blobdiff