Submit a Patch
Anybody can submit patches to fix bugs or implement new features in SharpSvn. Before submitting a patch, please read our coding guidelines. After you have submitted a couple of good patches, we might invite you to become a committer to the SharpSvn project.
We welcome anybody developing one of the features on the roadmap and submitting a patch. Before you do, we'd appreciate it if you get in touch with us first to discuss the implementation. Send an email to email@example.com.
Mail patches to firstname.lastname@example.org, starting the subject line with [PATCH]. This helps our patch manager spot patches right away. For example:
Subject: [PATCH] fix for issue 123
If the patch addresses a particular issue, include the issue number as well: "[PATCH] issue #1729: ...". Developers who are interested in that particular issue will know to read the mail.
A patch submission should contain one logical change; please don't mix unrelated changes in one submission — send separate emails instead.
Generate the patch using svn diff from the top of a Subversion trunk working copy. If the file you're diffing is not under revision control, you can achieve the same effect by using diff -u.
Please include a log message with your patch. A good log message helps potential reviewers understand the changes in your patch, and increases the likelihood that it will be applied. You can put the log message in the body of the email, or at the top of the patch attachment (see below). Either way, it should follow the guidelines given in Writing log messages , and be enclosed in triple square brackets, like so:
Fix issue #1729: Don't crash because of a missing file.
(frobnicate_file): Check that file exists before frobnicating.
The brackets are not actually part of the log message, they're just a way to clearly mark off the log message from its surrounding context.
If possible, send the patch as an attachment with a mime-type of text/x-diff, text/x-patch, or text/plain. Most people's mailreaders can display those inline, and having the patch as an attachment allows them to extract the patch from the message conveniently. Never send patches in archived or compressed form (e.g., tar, gzip, zip, bzip2), because that prevents people from reviewing the patch directly in their mailreaders.
If you can't attach the patch with one of these mime-types, or if the patch is very short, then it's okay to include it directly in the body of your message. But watch out: some mail editors munge inline patches by inserting unasked-for line breaks in the middle of long lines. If you think your mail software might do this, then please use an attachment instead.
If the patch implements a new feature, make sure to describe the feature completely in your mail; if the patch fixes a bug, describe the bug in detail and give a reproduction recipe. An exception to these guidelines is when the patch addresses a specific issue in the issues database — in that case, just refer to the issue number in your log message, as described in Writing log messages.
It is normal for patches to undergo several rounds of feedback and change before being applied. Don't be discouraged if your patch is not accepted immediately, it just means that there are a lot of eyes looking at every code submission, and it's a rare patch that doesn't have at least a little room for improvement. After reading people's responses to your patch, make the appropriate changes and resubmit, wait for the next round of feedback, and lather, rinse, repeat, until some committer applies it.
If you don't get a response for a while, and don't see the patch applied, it may just mean that people are really busy. Go ahead and repost, and don't hesitate to point out that you're still waiting for a response. One way to think of it is that patch management is highly parallizable, and we need you to shoulder your share of the management as well as the coding. Every patch needs someone to shepherd it through the process, and the person best qualified to do that is the original submitter.