X-Git-Url: http://www.privoxy.org/gitweb/?p=privoxy.git;a=blobdiff_plain;f=doc%2Fwebserver%2Fdeveloper-manual%2Fcvs.html;h=f455e0a4368c2e6f1622355d99ecef3c97ef1f34;hp=f864f0e864ca7ea433b1e41d22b059b343b01290;hb=b47cbf4db0d9e96ddba749f3b44e714f7288443b;hpb=72081f829de368392d04076728f8c991178c0080 diff --git a/doc/webserver/developer-manual/cvs.html b/doc/webserver/developer-manual/cvs.html index f864f0e8..f455e0a4 100644 --- a/doc/webserver/developer-manual/cvs.html +++ b/doc/webserver/developer-manual/cvs.html @@ -1,395 +1,162 @@ - -
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. -
The project's CVS repository is hosted on - SourceForge. - Please refer to the chapters 6 and 7 in - SF's site - documentation for the technical access details for your - operating system. For historical reasons, the CVS server is - called cvs.ijbswa.sourceforge.net, the repository is - called ijbswa, and the source tree module is called - current. -
Within the CVS repository, there are modules and branches. As - mentioned, the sources are in the current - "module". Other modules are present for platform specific - issues. There is a webview of the CVS hierarchy at http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ijbswa/, - which might help with visualizing how these pieces fit together. -
Branches are used to fork a sub-development path from the main trunk. - Within the current module where the sources are, there - is always at least one "branch" 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 only used for bugfixes, which have - had prior testing before being committed to CVS. (See Version Numbers below for details on - versioning.) -
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 cvs -r flag to check out a - branch, e.g: cvs co -r v_3_0_branch current. -
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: -
Basic Guidelines, for all branches: -
Never (read: never, ever) 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. -
Your commit message should give a concise overview of what you - changed (no big details) and why you changed it - Just check previous messages for good examples. -
Don't use the same message on multiple files, unless it equally applies to - all those files. -
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. -
Before changing things on CVS, make sure that your changes are in line - with the team's general consensus on what should be done. -
Note that near a major public release, we get more cautious. - There is always the possibility to submit a patch to the patch - tracker instead. -
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 - v_3_0_branch branch): -
Do not commit anything 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. -
Where possible, bugfixes and changes should be tested in the main - development trunk first. There may be occasions where this is not - feasible, though. -
Alternately, proposed changes can be submitted as patches to the patch tracker on - Sourceforge first: http://sourceforge.net/tracker/?group_id=11118&atid=311118. - Then ask for peer review. -
Do not even think about anything except bugfixes. No new features! -
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.
+ +The project's CVS repository is hosted on SourceForge. Please refer + to the chapters 6 and 7 in SF's site + documentation for the technical access details for your operating + system. For historical reasons, the CVS server is called ijbswa.cvs.sourceforge.net, the repository is called + ijbswa, and the source tree module is called + current.
+Within the CVS repository, there are modules and branches. As + mentioned, the sources are in the current + "module". Other modules are present for + platform specific issues. There is a webview of the CVS hierarchy at + http://ijbswa.cvs.sourceforge.net/ijbswa/, which might help + with visualizing how these pieces fit together.
+ +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.
+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. We expect anyone with CVS access to strictly adhere to + the following guidelines:
+ +Basic Guidelines, for all branches:
+ +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.
+Your commit message should give a concise overview of + what you + changed (no big details) and why you changed it Just + check previous messages for good examples.
+Don't use the same message on multiple files, unless it equally + applies to all those files.
+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.
+Before changing things on CVS, make sure that your changes are + in line with the team's general consensus on what should be + done.
+Note that near a major public release, we get more cautious. + There is always the possibility to submit a patch to the patch tracker instead.
+