| Privoxy Developer Manual | ||||
|---|---|---|---|---|
| Prev | - +Prev | - - | Next | +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.
- +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.
+The project's CVS repository is hosted on SourceForge. + 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.
+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/viewvc/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. 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:
- +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.
+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.
+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.
+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.
+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.
+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 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.