To subscribe to the lists above, simply send email to LISTNAME-subscribe@subversion.apache.org @@ -123,8 +126,11 @@
It's often useful to search the mailing list archives before posting or replying: someone may have already reported the bug @@ -157,8 +163,11 @@
If you only want to receive mail about important announcements (new releases of Subversion, for example), just subscribe @@ -167,8 +176,11 @@
We have a variety of additional mailing lists for other aspects of the project management. You can find these lists on Index: news.html =================================================================== --- news.html (revision 908111) +++ news.html (working copy) @@ -22,8 +22,11 @@ -
Subversion 1.6.9, the latest stable version of Subversion, has been released. For more information, see the @@ -34,8 +37,11 @@
The Subversion project has been accepted into the Apache Incubator, the Index: packages.html =================================================================== --- packages.html (revision 908111) +++ packages.html (working copy) @@ -55,8 +55,11 @@ ready. The packagers already know when new source releases come out, and work as fast as they can to make binaries available.
-This is a preliminary timetable for the next few upcoming releases. As noted above, we do not guarantee that a specific feature will @@ -58,8 +61,11 @@
Subversion uses a compromise between time-driven and feature-driven release planning. We schedule the next release for an approximate @@ -91,8 +97,11 @@
We try to have at least one or two new features under active development at any given time, but we generally don't rush a feature @@ -180,8 +189,11 @@
For information about past releases, see the release history.
Index: docs/community-guide/l10n.part.html =================================================================== --- docs/community-guide/l10n.part.html (revision 908111) +++ docs/community-guide/l10n.part.html (working copy) @@ -1,5 +1,8 @@ -Translation has been divided into two domains. First, there is the translation of server messages sent to connecting clients. This issue @@ -9,8 +12,11 @@ libraries.
-The gettext package provides services for translating messages. It uses the xgettext tool to extract strings from the sources for @@ -70,8 +76,11 @@
The Makefile build targets locale-gnu-* (used to maintain po files) require GNU gettext 0.13 or newer. Note that this is not a requirement @@ -80,8 +89,11 @@
Before starting a new translation please contact the subversion development mailing list to make sure you are not duplicating efforts. Also @@ -91,8 +103,11 @@
After that, you should perform the following steps:
-To be documented
See issue #1977.
@@ -175,8 +196,11 @@Before submitting to the mailing list or committing to the repository, please make sure your po file 'compiles'. You can do this with these @@ -195,8 +219,11 @@
Please don't mail large po files to the mailing lists. There are many subscribers on dev@subversion.apache.org who are on slow links and do @@ -212,8 +239,11 @@
The Makefile based part of the build system contains a make target to facilitate maintenance of existing po files. To update po files on @@ -249,8 +279,11 @@
Editing po files in trunk is pretty straightforward, but gets a bit more complicated when those changes are going to be transferred to a release @@ -290,8 +323,11 @@
On some gettext implementations we have to ensure that the mo files — whether obtained through the project or created @@ -313,8 +349,11 @@
Some gettext implementations use a section with a msgid "" (empty string) to keep administrative data. One of the headers suggested is @@ -330,8 +369,11 @@
The GNU translation project (http://www2.iro.umontreal.ca/~gnutra/po/HTML/) attempts to organise @@ -341,8 +383,11 @@
The project has standardised the use of quotes. Some translation teams have done the same. If there is no translation team for your @@ -352,8 +397,11 @@
Since translators will generally see all error messages in the code,
it's important to know that there is a
Index: docs/community-guide/issues.part.html
===================================================================
--- docs/community-guide/issues.part.html (revision 908111)
+++ docs/community-guide/issues.part.html (working copy)
@@ -1,5 +1,8 @@
- Subversion isn't perfect software. It contains bugs, lacks
features, and has room for improvement like any other piece of
@@ -60,8 +63,11 @@
The following are the policies that we ask folks to abide by when
reporting problems or requested enhancements to Subversion. First, make sure it's a bug. If Subversion does not behave the way
you expect, look in the documentation and mailing list archives for
@@ -140,8 +146,11 @@
When an issue is filed, it goes into the special milestone "---",
meaning unmilestoned. This is a holding area that issues
Index: docs/community-guide/general.part.html
===================================================================
--- docs/community-guide/general.part.html (revision 908111)
+++ docs/community-guide/general.part.html (working copy)
@@ -1,8 +1,14 @@
- Although Subversion was originally sponsored and hosted by
CollabNet (http://www.collab.net),
@@ -67,8 +73,11 @@
Design Before you can contribute code, you'll need to familiarize yourself
with the existing code base and interfaces. A rough guide to the source tree: The Subversion project strongly prefers that active development
happen in the common trunk. Changes made to trunk have the highest
@@ -289,8 +307,11 @@
task. The following are some guidelines to make your branch-based
development work go smoothly. There's nothing particularly complex about branch-based
development. You make a branch from the trunk (or from whatever
@@ -303,8 +324,11 @@
If you're working on a feature or bugfix in stages involving
multiple commits, and some of the intermediate stages aren't stable
@@ -337,8 +361,11 @@
For branches you expect to be longer-lived, we recommend the
creation and regular updating of a file in the root of your branch
@@ -395,11 +422,17 @@
Every function, whether public or internal, must start out with a
documentation comment that describes what the function does. The
@@ -474,8 +507,11 @@
We use the Doxygen format for
public interface documentation. This means anything that goes in a
@@ -509,8 +545,11 @@
Mail patches to dev@subversion.apache.org, starting the subject
line with [PATCH]. This helps our patch manager spot patches
Index: docs/community-guide/debugging.part.html
===================================================================
--- docs/community-guide/debugging.part.html (revision 908111)
+++ docs/community-guide/debugging.part.html (working copy)
@@ -1,11 +1,20 @@
- 'mod_dav_svn.so' contains the main Subversion server logic; it runs
as a module within mod_dav, which runs as a module within httpd.
@@ -39,8 +48,11 @@
Bugs in ra_svn usually manifest themselves with one of the
following cryptic error messages: Use Wireshark (formerly
known as "Ethereal") to eavesdrop on the conversation. Our use of APR pools makes it unusual for us to have memory leaks
in the strictest sense; all the memory we allocate will be cleaned up
Index: docs/community-guide/releasing.part.html
===================================================================
--- docs/community-guide/releasing.part.html (revision 908111)
+++ docs/community-guide/releasing.part.html (working copy)
@@ -1,8 +1,14 @@
- Subversion uses "MAJOR.MINOR.PATCH" release numbers, with the same
guidelines as APR (see
- If a release or candidate release needs to be quickly re-issued due
to some non-code problem (say, a packaging glitch), it's okay to reuse
@@ -175,8 +184,11 @@
When a new, improved version of an API is introduced, the old one
remains for compatibility, at least until the next major release.
@@ -228,8 +240,11 @@
Minor and major number releases go through a stabilization period
before release, and remain in maintenance (bugfix) mode after release.
@@ -458,8 +473,11 @@
NOTE: Changes to STATUS regarding the temporary branch, including
voting, are always kept on the main release branch. When we want new features to get wide testing before we enter the
formal stabilization period described above, we'll sometimes release
@@ -493,8 +511,11 @@
Before a release or release candidate is officially made public, it is
made available in a temporary location for committers to test and sign.
@@ -545,8 +566,11 @@
It is preferred to use the patch process and have your changes
accepted and applied to trunk to be released on the normal Subversion
@@ -577,8 +601,11 @@
A new release branch is created for each new major and minor
release. So, for example, a new release branch is created when
@@ -640,8 +667,11 @@
Once a release branch has been created, no development ever
takes place there. The only changes permitted are ones made to
@@ -656,8 +686,11 @@
The CHANGES file is the project changelog file. Before a
release, it must be brought up to date to list all changes since the
@@ -686,8 +719,11 @@
If it takes more than one line to describe, maybe I'm getting too
detailed? Run As part of release
stabilization, CHANGES should be updated as bug fixes are
@@ -726,8 +765,11 @@
So, a release branch has stabilized, and you are gearing up to roll
the release. Before you can actually roll the archives, you need to
@@ -798,8 +840,11 @@
Before rolling, first make sure that the latest version of the
CHANGES file from trunk is merged into the release branch, and that
@@ -938,8 +983,11 @@
Upload the tarballs to
http://subversion.tigris.org/downloads/. When someone with administrative access to svn.collab.net
has time available, they will upgrade it to the latest release or
Index: docs/community-guide/mailing-lists.part.html
===================================================================
--- docs/community-guide/mailing-lists.part.html (revision 908111)
+++ docs/community-guide/mailing-lists.part.html (working copy)
@@ -1,5 +1,8 @@
- The advice below is based on years of experience with the
Subversion mailing lists, and addresses the problems seen most
@@ -11,8 +14,11 @@
If you follow these conventions when posting to our mailing lists,
your post is much more likely to be read and answered. When in doubt, mail users@subversion.apache.org, not dev@subversion.apache.org.
@@ -40,8 +46,11 @@
Sometimes, when really impassioned about a topic, it's tempting to
respond to every message in a mail thread. Please don't do this. Our
@@ -57,11 +66,17 @@
Please don't use lines longer than 72 columns. Many people use
80-column terminals to read their email. By writing your text in 72
@@ -79,8 +94,11 @@
Capitalize the first letter of each sentence, and use paragraphs.
If you're showing screen output or some other sort of example, offset
@@ -93,11 +111,17 @@
Make sure to use your mailreader's "Follow-up" or "Reply-to-all" or
"Group reply" feature when responding to a list post. Otherwise, your
@@ -127,8 +151,11 @@
Don't start a new thread (subject) by replying to an existing
post. Instead, start a fresh mail, even if that means you have to
@@ -151,8 +178,11 @@
If you do need to change the Subject header while
preserving the thread (perhaps because the thread has wandered into
@@ -171,8 +201,11 @@
Please don't reflexively chide people for top-posting.
"Top-posting" is the practice of putting the response text above the
@@ -199,8 +232,11 @@
See here for advice on how to send in a
patch. Note that you can send in a patch to modify these web pages as
@@ -211,8 +247,11 @@
Please use ASCII or ISO-8859 text if possible. Don't post HTML
mails, RichText mails, or other formats that might be opaque to
Index: docs/community-guide/roles.part.html
===================================================================
--- docs/community-guide/roles.part.html (revision 908111)
+++ docs/community-guide/roles.part.html (working copy)
@@ -1,8 +1,14 @@
- Committers in the Subversion project are those folks to whom the
right to directly commit changes to our version controlled resources
@@ -18,8 +24,11 @@
>COMMITTERS file lists all committers, both full and partial, and
says the domains for each partial committer. After someone has successfully contributed a few non-trivial
patches, some full committer, usually whoever has reviewed and applied
@@ -63,8 +72,11 @@
A full committer sponsors the partial committer. Usually this
means the full committer has applied several patches to the same area
@@ -108,8 +120,11 @@
When a tool is accepted into the contrib/ area, we
automatically offer its author partial commit access to maintain the
@@ -124,8 +139,11 @@
Any committer, whether full or partial, may commit fixes for
obvious typos, grammar mistakes, and formatting problems wherever they
@@ -156,8 +174,11 @@
The role of the Release Manager in the Subversion project is to
handle the process of getting code stabilized, packaged and released
@@ -187,8 +208,11 @@
Subversion usually has a Patch Manager, whose job is to watch the
dev@ mailing list and make sure that no patches "slip through the
Index: docs/community-guide/building.part.html
===================================================================
--- docs/community-guide/building.part.html (revision 908111)
+++ docs/community-guide/building.part.html (working copy)
@@ -1,8 +1,14 @@
- Greg Stein wrote a custom build system for Subversion, which had
been using `automake' and recursive Makefiles. Now it uses a single,
@@ -217,8 +223,11 @@
For a description of how to use and add tests to Subversion's
automated test framework, please read
- Although Subversion was originally sponsored and hosted by
CollabNet (http://www.collab.net),
@@ -220,8 +226,11 @@
Design Before you can contribute code, you'll need to familiarize yourself
with the existing code base and interfaces. A rough guide to the source tree: The Subversion project strongly prefers that active development
happen in the common trunk. Changes made to trunk have the highest
@@ -442,8 +460,11 @@
task. The following are some guidelines to make your branch-based
development work go smoothly. There's nothing particularly complex about branch-based
development. You make a branch from the trunk (or from whatever
@@ -456,8 +477,11 @@
If you're working on a feature or bugfix in stages involving
multiple commits, and some of the intermediate stages aren't stable
@@ -490,8 +514,11 @@
For branches you expect to be longer-lived, we recommend the
creation and regular updating of a file in the root of your branch
@@ -548,11 +575,17 @@
Every function, whether public or internal, must start out with a
documentation comment that describes what the function does. The
@@ -627,8 +660,11 @@
We use the Doxygen format for
public interface documentation. This means anything that goes in a
@@ -662,8 +698,11 @@
Mail patches to dev@subversion.apache.org, starting the subject
line with [PATCH]. This helps our patch manager spot patches
@@ -755,11 +794,17 @@
Committers in the Subversion project are those folks to whom the
right to directly commit changes to our version controlled resources
@@ -775,8 +820,11 @@
>COMMITTERS file lists all committers, both full and partial, and
says the domains for each partial committer. After someone has successfully contributed a few non-trivial
patches, some full committer, usually whoever has reviewed and applied
@@ -820,8 +868,11 @@
A full committer sponsors the partial committer. Usually this
means the full committer has applied several patches to the same area
@@ -865,8 +916,11 @@
When a tool is accepted into the contrib/ area, we
automatically offer its author partial commit access to maintain the
@@ -881,8 +935,11 @@
Any committer, whether full or partial, may commit fixes for
obvious typos, grammar mistakes, and formatting problems wherever they
@@ -913,8 +970,11 @@
The role of the Release Manager in the Subversion project is to
handle the process of getting code stabilized, packaged and released
@@ -944,8 +1004,11 @@
Subversion usually has a Patch Manager, whose job is to watch the
dev@ mailing list and make sure that no patches "slip through the
@@ -979,11 +1042,17 @@
Subversion's code and headers files are segregated along a couple
of key lines: library-specific vs. inter-library; public vs. private.
@@ -1024,8 +1093,11 @@
Subversion uses ANSI C, and follows the GNU coding standards,
except that we do not put a space between the name of a function and
@@ -1069,8 +1141,11 @@
We're using page breaks (the Ctrl-L character, ASCII 12) for
section boundaries in both code and plaintext prose files. Each
@@ -1085,8 +1160,11 @@
For error messages the following conventions apply: (This assumes you already basically understand how APR pools work;
see apr_pools.h for details.) Always check for APR status codes (except APR_SUCCESS) with the
APR_STATUS_IS_...() macros, not by direct comparison. This is required
@@ -1342,8 +1426,11 @@
OK, here's how to use exceptions in Subversion. Just like almost any other programming language, C has undesirable
features which enables an attacker to make your program fail in
@@ -1625,8 +1715,11 @@
In addition to the GNU standards, Subversion uses these
conventions: Every commit needs a log message. It is very important to record code contributions in a consistent
and parseable way. This allows us to write scripts to figure out who
@@ -2139,11 +2238,17 @@
Greg Stein wrote a custom build system for Subversion, which had
been using `automake' and recursive Makefiles. Now it uses a single,
@@ -2358,8 +2463,11 @@
For a description of how to use and add tests to Subversion's
automated test framework, please read
- 'mod_dav_svn.so' contains the main Subversion server logic; it runs
as a module within mod_dav, which runs as a module within httpd.
@@ -2498,8 +2621,11 @@
Bugs in ra_svn usually manifest themselves with one of the
following cryptic error messages: Use Wireshark (formerly
known as "Ethereal") to eavesdrop on the conversation. Our use of APR pools makes it unusual for us to have memory leaks
in the strictest sense; all the memory we allocate will be cleaned up
@@ -2714,8 +2846,11 @@
The advice below is based on years of experience with the
Subversion mailing lists, and addresses the problems seen most
@@ -2727,8 +2862,11 @@
If you follow these conventions when posting to our mailing lists,
your post is much more likely to be read and answered. When in doubt, mail users@subversion.apache.org, not dev@subversion.apache.org.
@@ -2756,8 +2894,11 @@
Sometimes, when really impassioned about a topic, it's tempting to
respond to every message in a mail thread. Please don't do this. Our
@@ -2773,11 +2914,17 @@
Please don't use lines longer than 72 columns. Many people use
80-column terminals to read their email. By writing your text in 72
@@ -2795,8 +2942,11 @@
Capitalize the first letter of each sentence, and use paragraphs.
If you're showing screen output or some other sort of example, offset
@@ -2809,11 +2959,17 @@
Make sure to use your mailreader's "Follow-up" or "Reply-to-all" or
"Group reply" feature when responding to a list post. Otherwise, your
@@ -2843,8 +2999,11 @@
Don't start a new thread (subject) by replying to an existing
post. Instead, start a fresh mail, even if that means you have to
@@ -2867,8 +3026,11 @@
If you do need to change the Subject header while
preserving the thread (perhaps because the thread has wandered into
@@ -2887,8 +3049,11 @@
Please don't reflexively chide people for top-posting.
"Top-posting" is the practice of putting the response text above the
@@ -2915,8 +3080,11 @@
See here for advice on how to send in a
patch. Note that you can send in a patch to modify these web pages as
@@ -2927,8 +3095,11 @@
Please use ASCII or ISO-8859 text if possible. Don't post HTML
mails, RichText mails, or other formats that might be opaque to
@@ -2953,8 +3124,11 @@
Subversion isn't perfect software. It contains bugs, lacks
features, and has room for improvement like any other piece of
@@ -3015,8 +3189,11 @@
The following are the policies that we ask folks to abide by when
reporting problems or requested enhancements to Subversion. First, make sure it's a bug. If Subversion does not behave the way
you expect, look in the documentation and mailing list archives for
@@ -3095,8 +3272,11 @@
When an issue is filed, it goes into the special milestone "---",
meaning unmilestoned. This is a holding area that issues
@@ -3207,11 +3390,17 @@
Subversion uses "MAJOR.MINOR.PATCH" release numbers, with the same
guidelines as APR (see
- If a release or candidate release needs to be quickly re-issued due
to some non-code problem (say, a packaging glitch), it's okay to reuse
@@ -3384,8 +3576,11 @@
When a new, improved version of an API is introduced, the old one
remains for compatibility, at least until the next major release.
@@ -3437,8 +3632,11 @@
Minor and major number releases go through a stabilization period
before release, and remain in maintenance (bugfix) mode after release.
@@ -3667,8 +3865,11 @@
NOTE: Changes to STATUS regarding the temporary branch, including
voting, are always kept on the main release branch. When we want new features to get wide testing before we enter the
formal stabilization period described above, we'll sometimes release
@@ -3702,8 +3903,11 @@
Before a release or release candidate is officially made public, it is
made available in a temporary location for committers to test and sign.
@@ -3754,8 +3958,11 @@
It is preferred to use the patch process and have your changes
accepted and applied to trunk to be released on the normal Subversion
@@ -3786,8 +3993,11 @@
A new release branch is created for each new major and minor
release. So, for example, a new release branch is created when
@@ -3849,8 +4059,11 @@
Once a release branch has been created, no development ever
takes place there. The only changes permitted are ones made to
@@ -3865,8 +4078,11 @@
The CHANGES file is the project changelog file. Before a
release, it must be brought up to date to list all changes since the
@@ -3895,8 +4111,11 @@
If it takes more than one line to describe, maybe I'm getting too
detailed?Bugs / Issues
+Bugs / Issues
+ ¶
+
How to report a bug
+How to report a bug
+ ¶
+
Where to report a bug
+Where to report a bug
+ ¶
+
@@ -187,8 +196,11 @@
Issue triage
+Issue triage
+ ¶
+
General Overview
+General Overview
+ ¶
+
-Participating in the community
+Participating in the community
+ ¶
+
Theory and documentation
+Theory and documentation
+ ¶
+
Code to read
+Code to read
+ ¶
+
Directory layout
+Directory layout
+ ¶
+
Branching policy
+Branching policy
+ ¶
+
Branch creation and management
+Branch creation and management
+ ¶
+
Lightweight branches
+Lightweight branches
+ ¶
+
BRANCH-README files
+BRANCH-README files
+ ¶
+
Documentation
+Documentation
+ ¶
+
-Document Everything
+Document Everything
+ ¶
+
Public API Documentation
+Public API Documentation
+ ¶
+
Patch submission guidelines
+Patch submission guidelines
+ ¶
+
Debugging Subversion
+Debugging Subversion
+ ¶
+
-Debugging the server
+Debugging the server
+ ¶
+
-Debugging the DAV server
+Debugging the DAV server
+ ¶
+
Debugging the ra_svn client and server, on Unix
+Debugging the ra_svn client and server, on Unix
+ ¶
+
Tracing network traffic
+Tracing network traffic
+ ¶
+
Tracking down memory leaks
+Tracking down memory leaks
+ ¶
+
Making Subversion Releases
+Making Subversion Releases
+ ¶
+
-Release numbering, compatibility, and deprecation
+Release numbering, compatibility, and deprecation
+ ¶
+
Reuse of release names
+Reuse of release names
+ ¶
+
Deprecation
+Deprecation
+ ¶
+
Stabilizing and maintaining releases
+Stabilizing and maintaining releases
+ ¶
+
Alpha and beta releases
+Alpha and beta releases
+ ¶
+
Signing source distribution packages (a.k.a tarballs)
+Signing source distribution packages (a.k.a tarballs)
+ ¶
+
Custom releases
+Custom releases
+ ¶
+
Creating and maintaining release branches
+Creating and maintaining release branches
+ ¶
+
Porting changes to release branches
+Porting changes to release branches
+ ¶
+
Managing the CHANGES file
+Managing the CHANGES file
+ ¶
+
Writing the initial content for a branch
+Writing the initial content for a branch
+ ¶
+
svn log -rHEAD:BRANCH_POINT
http://svn.apache.org/repos/asf/subversion/branches/A.B.x,where
@@ -711,7 +747,10 @@
Adding content for patch release
+Adding content for patch release
+ ¶
+
Preparing to roll a release
+Preparing to roll a release
+ ¶
+
Rolling a release
+Rolling a release
+ ¶
+
The actual releasing
+The actual releasing
+ ¶
+
After a release has been made
+After a release has been made
+ ¶
+
Mailing Lists
+Mailing Lists
+ ¶
+
Where to post
+Where to post
+ ¶
+
When to post
+When to post
+ ¶
+
Formatting
+Formatting
+ ¶
+
-Line Length
+Line Length
+ ¶
+
Capitalization
+Capitalization
+ ¶
+
Replying
+Replying
+ ¶
+
-Reply-To
+Reply-To
+ ¶
+
Making a fresh post
+Making a fresh post
+ ¶
+
Re-threading
+Re-threading
+ ¶
+
Top-Posting
+Top-Posting
+ ¶
+
Sending patches
+Sending patches
+ ¶
+
Languages and encodings
+Languages and encodings
+ ¶
+
Community Roles
+Community Roles
+ ¶
+
-Committers
+Committers
+ ¶
+
How full commit access is granted
+How full commit access is granted
+ ¶
+
How partial commit access is granted
+How partial commit access is granted
+ ¶
+
The contrib/ area
+The contrib/ area
+ ¶
+
The "obvious fix" rule
+The "obvious fix" rule
+ ¶
+
Release Manager
+Release Manager
+ ¶
+
Patch Manager
+Patch Manager
+ ¶
+
Building and Testing
+Building and Testing
+ ¶
+
-The configuration/build system under unix
+The configuration/build system under unix
+ ¶
+
Automated tests
+Automated tests
+ ¶
+
Build farm
+
-Writing test cases before code
+Writing test cases before code
+ ¶
+
From: Karl Fogel <kfogel@collab.net>
Index: docs/community-guide/index.html
===================================================================
--- docs/community-guide/index.html (revision 908111)
+++ docs/community-guide/index.html (working copy)
@@ -151,11 +151,17 @@
General Overview
+General Overview
+ ¶
+
-Participating in the community
+Participating in the community
+ ¶
+
Theory and documentation
+Theory and documentation
+ ¶
+
Code to read
+Code to read
+ ¶
+
Directory layout
+Directory layout
+ ¶
+
Branching policy
+Branching policy
+ ¶
+
Branch creation and management
+Branch creation and management
+ ¶
+
Lightweight branches
+Lightweight branches
+ ¶
+
BRANCH-README files
+BRANCH-README files
+ ¶
+
Documentation
+Documentation
+ ¶
+
-Document Everything
+Document Everything
+ ¶
+
Public API Documentation
+Public API Documentation
+ ¶
+
Patch submission guidelines
+Patch submission guidelines
+ ¶
+
Community Roles
+Community Roles
+ ¶
+
-Committers
+Committers
+ ¶
+
How full commit access is granted
+How full commit access is granted
+ ¶
+
How partial commit access is granted
+How partial commit access is granted
+ ¶
+
The contrib/ area
+The contrib/ area
+ ¶
+
The "obvious fix" rule
+The "obvious fix" rule
+ ¶
+
Release Manager
+Release Manager
+ ¶
+
Patch Manager
+Patch Manager
+ ¶
+
Coding and Commit Conventions
+Coding and Commit Conventions
+ ¶
+
-Code modularity and interface visibility
+Code modularity and interface visibility
+ ¶
+
Coding style
+Coding style
+ ¶
+
Using page breaks
+Using page breaks
+ ¶
+
Error message conventions
+Error message conventions
+ ¶
+
APR pool usage conventions
+APR pool usage conventions
+ ¶
+
APR status codes
+APR status codes
+ ¶
+
Exception handling
+Exception handling
+ ¶
+
Secure coding guidelines
+Secure coding guidelines
+ ¶
+
Other coding conventions
+Other coding conventions
+ ¶
+
Writing log messages
+Writing log messages
+ ¶
+
Crediting
+Crediting
+ ¶
+
Building and Testing
+Building and Testing
+ ¶
+
-The configuration/build system under unix
+The configuration/build system under unix
+ ¶
+
Automated tests
+Automated tests
+ ¶
+
Build farm
+
-Writing test cases before code
+Writing test cases before code
+ ¶
+
From: Karl Fogel <kfogel@collab.net>
@@ -2457,14 +2571,23 @@
Debugging Subversion
+Debugging Subversion
+ ¶
+
-Debugging the server
+Debugging the server
+ ¶
+
-Debugging the DAV server
+Debugging the DAV server
+ ¶
+
Debugging the ra_svn client and server, on Unix
+Debugging the ra_svn client and server, on Unix
+ ¶
+
Tracing network traffic
+Tracing network traffic
+ ¶
+
Tracking down memory leaks
+Tracking down memory leaks
+ ¶
+
Mailing Lists
+Mailing Lists
+ ¶
+
Where to post
+Where to post
+ ¶
+
When to post
+When to post
+ ¶
+
Formatting
+Formatting
+ ¶
+
-Line Length
+Line Length
+ ¶
+
Capitalization
+Capitalization
+ ¶
+
Replying
+Replying
+ ¶
+
-Reply-To
+Reply-To
+ ¶
+
Making a fresh post
+Making a fresh post
+ ¶
+
Re-threading
+Re-threading
+ ¶
+
Top-Posting
+Top-Posting
+ ¶
+
Sending patches
+Sending patches
+ ¶
+
Languages and encodings
+Languages and encodings
+ ¶
+
Bugs / Issues
+Bugs / Issues
+ ¶
+
How to report a bug
+How to report a bug
+ ¶
+
Where to report a bug
+Where to report a bug
+ ¶
+
@@ -3142,8 +3322,11 @@
Issue triage
+Issue triage
+ ¶
+
Making Subversion Releases
+Making Subversion Releases
+ ¶
+
-Release numbering, compatibility, and deprecation
+Release numbering, compatibility, and deprecation
+ ¶
+
Reuse of release names
+Reuse of release names
+ ¶
+
Deprecation
+Deprecation
+ ¶
+
Stabilizing and maintaining releases
+Stabilizing and maintaining releases
+ ¶
+
Alpha and beta releases
+Alpha and beta releases
+ ¶
+
Signing source distribution packages (a.k.a tarballs)
+Signing source distribution packages (a.k.a tarballs)
+ ¶
+
Custom releases
+Custom releases
+ ¶
+
Creating and maintaining release branches
+Creating and maintaining release branches
+ ¶
+
Porting changes to release branches
+Porting changes to release branches
+ ¶
+
Managing the CHANGES file
+Managing the CHANGES file
+ ¶
+
Writing the initial content for a branch
+Writing the initial content for a branch
+