Open Source <opensrc_inf@yahoo.com> writes:
> I was trying to get the test cases to work with 727
> release. One particular test case related to fs-tests
> segment faults on Suze linux 7.3.
> Test case: verify_path_revs
Thanks -- here's the section from the BUGS file about how to write a
bug report that helps us reproduce the problem:
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.
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. If there are files involved, give the contents of the files.
The very best thing is to package your reproduction recipe as a
script, that helps us a lot.
[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. Also, make sure your APR tree is
up-to-date.]
In addition to the reproduction recipe, we'll also need a complete
description of the environment in which you reproduced the bug.
That means:
- Your operating system
- The release and/or revision of Subversion
- The compiler and configuration options you built Subversion with
- Any private modifications you made to your Subversion
- The version of Berkeley DB you're running Subversion with
- Anything else that could possibly be relevant. Err on the side
of too much information, rather than too little.
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 the HACKING file for
more information about writing patches.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:55 2006