Before filing a new issue, please:
Re-read the documentation
(especially the FAQ and the
online Subversion book).
Look through all existing issues, or search their summaries:
to see if this bug has already been reported.
Report your problem to users@subversion.tigris.org,
describing the bug or feature request that you were about to file.
People there will ask you questions and help get the bug report
into a useful form, after verifying that a new issue is appropriate.
(See http://svn.collab.net/repos/svn/trunk/BUGS for how
to write a useful bug report.)
We depend on the mailing list as a first level of filtering for our bug tracker. Without it, the tracker would be full of duplicate issues, non-issues, and unreproducible issues. Please help us keep the bug database clean, by always posting to the list first!
When mailing the list with a concern, make sure that your e-mail describes your bug or enhancement fully. Provide details about the versions of the relevant software (Subversion, Apache, neon, etc.) that you are using, about your operating system, and about any other thing that might seem pertinent to the issue. If you can provide a script which consistently reproduces a problem, that can be incredibly helpful to those evaluating and/or working on your issue.
After mailing the list, you should expect your concern to be addressed with relative immediacy. That is, within a few days, you should get feedback on your mail. If indeed you have found a new bug in Subversion, or if your enhancement request is feasible, you will likely be asked to return here and file a new issue in the Issue Tracker.
When you file the issue, don't forget to include links to the relevant mailing list threads. Those are important context for anyone reading the issue, and their presence also confirms that the issue has already been discussed on the mailing list. Without them, the issue may get accidentally closed because no one can tell that it is the product of a list discussion.
When an issue is first filed, it automatically goes in the "---" target milestone, which indicates that the issue has not yet been processed. A developer will examine it and maybe talk to other developers, then estimate the bug's severity, the effort required to fix it, and schedule it in a numbered milestone, for example 1.1. (Or they may put it the unscheduled or nonblocking milestone, if they consider it tolerable for all currently planned releases.)
An issue filed in unscheduled might still get fixed soon, if some committer decides they want it done. Putting it in unscheduled merely means it hasn't been scheduled for any particular release yet. The nonblocking milestone, on the other hand, means that we do not anticipate ever scheduling the issue for a particular release. This also does not mean the issue will never be fixed; it merely means that we don't plan to block any release on it.
Severity is represented in the Priority field. Here is how priority numbers map to severity:
Effort Required is represented in the Status Whiteboard with an "e number", which is the average of the most optimistic and most pessimistic projections for number of engineer/days needed to fix the bug. The e number always comes first, so we can sort on the field, but we include the actual spread after it, so we know when we're dealing with a wide range. For example "e2.5 (2 / 3)" is not quite the same as "e2.5 (1 / 4)"!
And so, with further ado, we give you (drumroll…) the Subversion Issue Tracker.