The official source of information about the Subversion project is, of course, the project's website at http://subversion.tigris.org/. There you can find information about getting access to the source code and participating on the discussion lists. The Subversion community always welcomes new members. If you are interested in participating in this community by contributing changes to the source code, here are some hints on how to get started.
The first step in community participation is to find a way
to stay on top of the latest happenings. To do this most
effectively, you will want to subscribe to the main developer
discussion list (
commit mail list (
By following these lists even loosely, you will have access
to important design discussions, be able to see actual changes
to Subversion source code as they occur, and be able to
witness peer reviews of those changes and proposed changes.
These email based discussion lists are the primary
communication media for Subversion development. See the
Mailing Lists section of the website for other
Subversion-related lists you might be interested in.
But how do you know what needs to be done? It is quite common for a programmer to have the greatest intentions of helping out with the development, yet be unable to find a good starting point. After all, not many folks come to the community having already decided on a particular itch they would like to scratch. But by watching the developer discussion lists, you might see mentions of existing bugs or feature requests fly by that particularly interest you. Also, a great place to look for outstanding, unclaimed tasks is the Issue Tracking database on the Subversion website. There you will find the current list of known bugs and feature requests. If you want to start with something small, look for issues marked as “bite-sized”.
To edit the code, you need to have the code. This means
you need to check out a working copy from the public
Subversion source repository. As straightforward as that
might sound, the task can be slightly tricky. Because
Subversion's source code is versioned using Subversion itself,
you actually need to “bootstrap” by getting a
working Subversion client via some other method. The most
common methods include downloading the latest binary
distribution (if such is available for your platform), or
downloading the latest source tarball and building your own
Subversion client. If you build from source, make sure to
INSTALL file in the top level of
the source tree for instructions.
$ svn checkout http://svn.collab.net/repos/svn/trunk subversion A subversion/HACKING A subversion/INSTALL A subversion/README A subversion/autogen.sh A subversion/build.conf …
The above command will checkout the bleeding-edge, latest
version of the Subversion source code into a subdirectory
subversion in your current working
directory. Obviously, you can adjust that last argument as
you see fit. Regardless of what you call the new working copy
directory, though, after this operation completes, you will
now have the Subversion source code. Of course, you will
still need to fetch a few helper libraries (apr, apr-util,
INSTALL file in the
top level of the working copy for details.
Now that you have a working copy containing the latest
Subversion source code, you will most certainly want to take a
cruise through the “Hacker's Guide to Subversion”,
which is available either as the
www/hacking.html file in the working copy,
or on the Subversion website at http://subversion.tigris.org/hacking.html. This guide
contains general instructions for contributing to Subversion,
including how to properly format your source code for
consistency with the rest of the codebase, how to describe your
proposed changes with an effective change log message, how to
test your changes, and so on. Commit privileges on the
Subversion source repository are earned—a government by
The “Hacker's Guide” is an invaluable resource when
it comes to making sure that your proposed changes earn the
praises they deserve without being rejected on
With the code and community policy understanding in hand, you are ready to make your changes. It is best to try to make smaller but related sets of changes, even tackling larger tasks in stages, instead of making huge, sweeping modifications. Your proposed changes will be easier to understand (and therefore easier to review) if you disturb the fewest lines of code possible to accomplish your task properly. After making each set of proposed changes, your Subversion tree should be in a state in which the software compiles with no warnings.
Subversion has a fairly thorough  regression test suite, and your proposed changes are expected to not cause any of those tests to fail. By running make check (in Unix) from the top of the source tree, you can sanity-check your changes. The fastest way to get your code contributions rejected (other than failing to supply a good log message) is to submit changes that cause failure in the test suite.
In the best-case scenario, you will have actually added
appropriate tests to that test suite which verify that your
proposed changes work as expected. In fact,
sometimes the best contribution a person can make is solely
the addition of new tests. You can write regression tests for
functionality that currently works in Subversion as a way to
protect against future changes that might trigger failure in
those areas. Also, you can write new tests that demonstrate
known failures. For this purpose, the Subversion test suite
allows you to specify that a given test is expected to fail
XFAIL), and so long as
Subversion fails in the way that was expected, a test result
XFAIL itself is considered a success.
Ultimately, the better the test suite, the less time wasted on
diagnosing potentially obscure regression bugs.
After making your modifications to the source code, compose a clear and concise log message to describe those changes and the reasons for them. Then, send an email to the developers list containing your log message and the output of svn diff (from the top of your Subversion working copy). If the community members consider your changes acceptable, someone who has commit privileges (permission to make new revisions in the Subversion source repository) will add your changes to the public source code tree. Recall that permission to directly commit changes to the repository is granted on merit—if you demonstrate comprehension of Subversion, programming competency, and a “team spirit”, you will likely be awarded that permission.
 Note that the URL checked out in the example above
ends not with
svn, but with a
subdirectory thereof called
our discussion of Subversion's branching and tagging model
for the reasoning behind this.
 While this may superficially appear as some sort of elitism, this “earn your commit privileges” notion is about efficiency—whether it costs more in time and effort to review and apply someone else's changes that are likely to be safe and useful, versus the potential costs of undoing changes that are dangerous.
 You might want to grab some popcorn. “Thorough”, in this instance, translates to somewhere in the neighborhood of thirty minutes of non-interactive machine churn.