www/bugs.html - subversion - Git at Google

 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
 <style type="text/css"> /* <![CDATA[ */
   @import "branding/css/tigris.css";
   @import "branding/css/inst.css";
   /* ]]> */</style>
 <link rel="stylesheet" type="text/css" media="print"
   href="branding/css/print.css"/>
 <script type="text/javascript" src="branding/scripts/tigris.js"></script>
 <title>Reporting Bugs in Subversion</title>
 </head>

 <body>
 <div class="app">

 <h1 style="text-align: center;">Reporting Bugs in Subversion</h1>

 <p>This document tells how and where to report bugs.  (It is not a
 list of all outstanding bugs&nbsp;&mdash;&nbsp;you can get that
 <a
 href="http://subversion.tigris.org/issues/buglist.cgi?component=subversion&amp;issue_status=UNCONFIRMED&amp;issue_status=NEW&amp;issue_status=STARTED&amp;issue_status=REOPENED&amp;order=issues.target_milestone%2C%20issues.priority%2C%20issues.issue_type">here</a> instead.)</p>


 <div class="h2" id="where" title="where">
 <h2>Where To Report A Bug</h2>

 <ul>

 <li><p>If the bug is in Subversion itself, send mail to
     <a href="mailto:users@subversion.tigris.org"
                    >users@subversion.tigris.org</a>.
     Once it's confirmed as a bug, someone, possibly you, can enter it
     into the <a href="project_issues.html">issue tracker</a>.  (Or if
     you're pretty sure about the bug, go ahead and post directly to
     our development list, <a href="mailto:dev@subversion.tigris.org"
     >dev@subversion.tigris.org</a>.  But if you're not sure, it's
     better to post to <a href="mailto:users@subversion.tigris.org"
     >users@</a> first; someone there can tell you whether the behavior
     you encountered is expected or not.)</p></li>

 <li><p>If the bug is in the APR library, please report it to both of
     these mailing lists:
     <a href="mailto:dev@apr.apache.org">dev@apr.apache.org</a>,
     <a href="mailto:dev@subversion.tigris.org"
                    >dev@subversion.tigris.org</a>.</p></li>

 <li><p>If the bug is in the Neon HTTP library, please report it to:
      <a href="mailto:neon@webdav.org">neon@webdav.org</a>,
      <a href="mailto:dev@subversion.tigris.org"
                     >dev@subversion.tigris.org</a>.</p></li>

 <li><p>If the bug is in Apache HTTPD 2.0, please report it to both of
      these mailing lists: <a href="mailto:dev@httpd.apache.org"
      >dev@httpd.apache.org</a>,
      <a href="mailto:dev@subversion.tigris.org"
      >dev@subversion.tigris.org</a>.
      The Apache httpd developer mailing list is high-traffic, so your
      bug report post has the possibility to be overlooked.  You may also
      file a bug report at <a href="http://httpd.apache.org/bug_report.html"
      >http://httpd.apache.org/bug_report.html</a>.</p></li>

 <li><p>If the bug is in your rug, please give it a hug and keep it
     snug.</p></li>

 </ul>

 </div>

 <div class="h2" id="how" title="how">
 <h2>How To Report A Bug</h2>

 <p>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
 evidence that it should behave the way you expect.  Of course, if it's
 a common-sense thing, like Subversion just destroyed your data and
 caused smoke to pour out of your monitor, then you can trust your
 judgement.  But if you're not sure, go ahead and ask on the users
 mailing list first, <a href="mailto:users@subversion.tigris.org"
 >users@subversion.tigris.org</a>, or ask in IRC, <a
 href="irc://irc.freenode.net/#svn">irc.freenode.net, channel #svn</a>.</p>

 <p>Once you've established that it's a bug, the most important thing
 you can do is come up with a simple description and reproduction
 recipe.  For example, if the bug, as you initially found it, involves
 five files over ten commits, try to make it happen with just one file
 and one commit.  The simpler the reproduction recipe, the more likely
 a developer is to successfully reproduce the bug and fix it.</p>

 <p>When you write up the reproduction recipe, don't just write a prose
 description of what you did to make the bug happen.  Instead, give a
 literal transcript of the exact series of commands you ran, and their
 output.  Use cut-and-paste to do this.  If there are files involved,
 be sure to include the names of the files, and even their content if
 you think it might be relevant.  The very best thing is to package
 your reproduction recipe as a script, that helps us a lot.</p>

 <p><i>Quick sanity check: you *are* running the most recent version of
 Subversion, right? :-) Possibly the bug has already been fixed; you
 should test your reproduction recipe against the most recent
 Subversion development tree.</i></p>

 <p>In addition to the reproduction recipe, we'll also need a complete
 description of the environment in which you reproduced the bug.  That
 means:</p>

 <ul>
 <li>Your operating system</li>
 <li>The release and/or revision of Subversion</li>
 <li>The compiler and configuration options you built Subversion with</li>
 <li>Any private modifications you made to your Subversion</li>
 <li>The version of Berkeley DB you're running Subversion with, if any</li>
 <li>Anything else that could possibly be relevant.  Err on the side
     of too much information, rather than too little.</li>
 </ul>

 <p>Once you have all this, you're ready to write the report.  Start
 out with a clear description of what the bug is.  That is, say how you
 expected Subversion to behave, and contrast that with how it actually
 behaved.  While the bug may seem obvious to you, it may not be so
 obvious to someone else, so it's best to avoid a guessing game.
 Follow that with the environment description, and the reproduction
 recipe.  If you also want to include speculation as to the cause, and
 even a patch to fix the bug, that's great&nbsp;&mdash;&nbsp;see <a
 href="hacking.html#patches">hacking.html#patches</a> for instructions
 on sending patches.</p>

 <p>Post all of this information to <a
 href="mailto:dev@subversion.tigris.org"
 >dev@subversion.tigris.org</a>, or if you have already been there and
 been asked to file an issue, then go to the <a
 href="project_issues.html">Issue Tracker</a> and follow the
 instructions there.</p>

 <p>Thanks.  We know it's a lot of work to file an effective bug
 report, but a good report can save hours of a developer's time, and
 make the bug much more likely to get fixed.</p>

 </div>
 </div>
 </body>
 </html>
	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
	<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
	<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
	<style type="text/css"> /* <![CDATA[ */
	@import "branding/css/tigris.css";
	@import "branding/css/inst.css";
	/* ]]> */</style>
	<link rel="stylesheet" type="text/css" media="print"
	href="branding/css/print.css"/>
	<script type="text/javascript" src="branding/scripts/tigris.js"></script>
	<title>Reporting Bugs in Subversion</title>
	</head>

	<body>
	<div class="app">

	<h1 style="text-align: center;">Reporting Bugs in Subversion</h1>

	<p>This document tells how and where to report bugs. (It is not a
	list of all outstanding bugs — you can get that
	<a
	href="http://subversion.tigris.org/issues/buglist.cgi?component=subversion&issue_status=UNCONFIRMED&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&order=issues.target_milestone%2C%20issues.priority%2C%20issues.issue_type">here</a> instead.)</p>


	<div class="h2" id="where" title="where">
	<h2>Where To Report A Bug</h2>

	<ul>

	<li><p>If the bug is in Subversion itself, send mail to
	<a href="mailto:users@subversion.tigris.org"
	>users@subversion.tigris.org</a>.
	Once it's confirmed as a bug, someone, possibly you, can enter it
	into the <a href="project_issues.html">issue tracker</a>. (Or if
	you're pretty sure about the bug, go ahead and post directly to
	our development list, <a href="mailto:dev@subversion.tigris.org"
	>dev@subversion.tigris.org</a>. But if you're not sure, it's
	better to post to <a href="mailto:users@subversion.tigris.org"
	>users@</a> first; someone there can tell you whether the behavior
	you encountered is expected or not.)</p></li>

	<li><p>If the bug is in the APR library, please report it to both of
	these mailing lists:
	<a href="mailto:dev@apr.apache.org">dev@apr.apache.org</a>,
	<a href="mailto:dev@subversion.tigris.org"
	>dev@subversion.tigris.org</a>.</p></li>

	<li><p>If the bug is in the Neon HTTP library, please report it to:
	<a href="mailto:neon@webdav.org">neon@webdav.org</a>,
	<a href="mailto:dev@subversion.tigris.org"
	>dev@subversion.tigris.org</a>.</p></li>

	<li><p>If the bug is in Apache HTTPD 2.0, please report it to both of
	these mailing lists: <a href="mailto:dev@httpd.apache.org"
	>dev@httpd.apache.org</a>,
	<a href="mailto:dev@subversion.tigris.org"
	>dev@subversion.tigris.org</a>.
	The Apache httpd developer mailing list is high-traffic, so your
	bug report post has the possibility to be overlooked. You may also
	file a bug report at <a href="http://httpd.apache.org/bug_report.html"
	>http://httpd.apache.org/bug_report.html</a>.</p></li>

	<li><p>If the bug is in your rug, please give it a hug and keep it
	snug.</p></li>

	</ul>

	</div>

	<div class="h2" id="how" title="how">
	<h2>How To Report A Bug</h2>

	<p>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
	evidence that it should behave the way you expect. Of course, if it's
	a common-sense thing, like Subversion just destroyed your data and
	caused smoke to pour out of your monitor, then you can trust your
	judgement. But if you're not sure, go ahead and ask on the users
	mailing list first, <a href="mailto:users@subversion.tigris.org"
	>users@subversion.tigris.org</a>, or ask in IRC, <a
	href="irc://irc.freenode.net/#svn">irc.freenode.net, channel #svn</a>.</p>

	<p>Once you've established that it's a bug, the most important thing
	you can do is come up with a simple description and reproduction
	recipe. For example, if the bug, as you initially found it, involves
	five files over ten commits, try to make it happen with just one file
	and one commit. The simpler the reproduction recipe, the more likely
	a developer is to successfully reproduce the bug and fix it.</p>

	<p>When you write up the reproduction recipe, don't just write a prose
	description of what you did to make the bug happen. Instead, give a
	literal transcript of the exact series of commands you ran, and their
	output. Use cut-and-paste to do this. If there are files involved,
	be sure to include the names of the files, and even their content if
	you think it might be relevant. The very best thing is to package
	your reproduction recipe as a script, that helps us a lot.</p>

	<p><i>Quick sanity check: you are running the most recent version of
	Subversion, right? :-) Possibly the bug has already been fixed; you
	should test your reproduction recipe against the most recent
	Subversion development tree.</i></p>

	<p>In addition to the reproduction recipe, we'll also need a complete
	description of the environment in which you reproduced the bug. That
	means:</p>

	<ul>
	<li>Your operating system</li>
	<li>The release and/or revision of Subversion</li>
	<li>The compiler and configuration options you built Subversion with</li>
	<li>Any private modifications you made to your Subversion</li>
	<li>The version of Berkeley DB you're running Subversion with, if any</li>
	<li>Anything else that could possibly be relevant. Err on the side
	of too much information, rather than too little.</li>
	</ul>

	<p>Once you have all this, you're ready to write the report. Start
	out with a clear description of what the bug is. That is, say how you
	expected Subversion to behave, and contrast that with how it actually
	behaved. While the bug may seem obvious to you, it may not be so
	obvious to someone else, so it's best to avoid a guessing game.
	Follow that with the environment description, and the reproduction
	recipe. If you also want to include speculation as to the cause, and
	even a patch to fix the bug, that's great — see <a
	href="hacking.html#patches">hacking.html#patches</a> for instructions
	on sending patches.</p>

	<p>Post all of this information to <a
	href="mailto:dev@subversion.tigris.org"
	>dev@subversion.tigris.org</a>, or if you have already been there and
	been asked to file an issue, then go to the <a
	href="project_issues.html">Issue Tracker</a> and follow the
	instructions there.</p>

	<p>Thanks. We know it's a lot of work to file an effective bug
	report, but a good report can save hours of a developer's time, and
	make the bug much more likely to get fixed.</p>

	</div>
	</div>
	</body>
	</html>