| - Privoxy Developer Manual - | -||
|---|---|---|
| - Prev - | -- | -- Next - | -
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.
- 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. -
-- 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.) -
-- 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. 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: -
--
-- 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. -
-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.
+ +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.)
+ +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.
| - Prev - | -- Home - | -- Next - | -
| - Introduction - | -- - | -- Documentation Guidelines - | -
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:
+ +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.
+