How to submit a patch
Anybody can submit patches to fix bugs or implement new features
in AnkhSVN. 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 AnkhSVN 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
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
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
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
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.