Add CHANGES file, pre-written for the 1.1.0 release.
[cvs2svn.git] / BUGS
blobf0c46a6a1819d5f926da1a6cba38f21579578c21
1                                                        -*- text -*-
3                         REPORTING BUGS
4                         ==============
6 This document tells how and where to report bugs in cvs2svn.  It is
7 not a list of all outstanding bugs -- we use an online issue tracker
8 for that, see
10    http://cvs2svn.tigris.org/issue_tracker.html
12 Before reporting a bug, check to see
14    a) if you are already running the latest version of cvs2svn
16    b) if your bug is already filed in the issue tracker (see
17       http://tinyurl.com/2uxwv for a list of all open bugs).
19 Then, mail your bug report to dev@cvs2svn.tigris.org.
21 To be useful, a bug report should include the following information:
23    * The revision of cvs2svn you ran.  Look for a line like
24      "$LastChangedRevision: 789 $" near the top of cvs2svn (the
25      number will probably be different, of course).
27    * The version of Subversion you used it with.
29    * The exact cvs2svn command line you invoked, and the output it
30      produced.
32    * The data you ran it on.  If your CVS repository is small (only a
33      few kilobytes), then just provide the repository itself.  If it's
34      large, or if the data is confidential, then please try to come up
35      with some smaller, releasable data set that still stimulates the
36      bug.  Often this is just a matter of invoking cvs2svn on deeper
37      subdirectories, until you find the minimal reproduction case.
39 The most important thing is that we be able to reproduce the bug :-).
40 If we can reproduce it, we can usually fix it.  If we can't reproduce
41 it, we'll probably never fix it.  So describing the bug conditions
42 accurately is crucial.  If in addition to that, you want to add some
43 speculations as to the cause of the bug, or even include a patch to
44 fix it, that's great!
46 Thank you in advance,
47 -The cvs2svn development team