There are a lot of different things you can do to help Subversion. Not all involve coding; there are plenty of non-programming roles for eager volunteers.
Below are some of the needs we've identified, but please don't take these as gospel! New volunteers bring fresh viewpoints, and one of the most important things you can do is point out a need we hadn't recognized before — and then fill it.
These are the ideas that the Subversion developers have for Google Summer of Code applicants. These are just some ideas — if you have other ideas, we're happy to consider them too, please just post them to dev@subversion.tigris.org.
However, please don't select tasks in the other sections of this page as your Summer of Code proposal, as those are either not the right size for the Summer of Code, or are not coding tasks and therefore not eligible.
You should also read the Hacker's Guide to Subversion before starting out on a proposal. Don't hesitate to ask for details or start discussing one of these tasks on the dev@subversion.tigris.org mailing list (see here for subscription information).
In fact, please discuss your task on the mailing list regardless of whether you've submitted your application yet. Eagerness to engage with the rest of the Subversion development community will be considered favourable in evaluating your application.
If you have questions about the application process, compensation, or the Google Summer of Code program in general, please see the program FAQ
See issue #1167.
See also issue 2325 (svn cleanup should follow svn:external references).
Improve the progress output displayed during update and commit.
See Issue #1264 and issue #901.
Fully customizable external diff invocations, and support for external diff commands for non-text types.
See Issue #2044 and issue #2447.
Note: Summer of Code may require two or more depending on complexity.
2445: Allow users to change passwords.
2958/2662: Authz path wildcards; these are probably duplicate issues, and the latter one has a patch already, though it may be out-of-date now.
2338 mod_authz_svn should be able to use httpd's groups config.
2143 Additional authz action controls (e.g., add/remove files).
See issue #3065.
Interactive conflict resolution in the command line client should be taught about tree conflicts.
See issue #3144.
Subclipse has taken an interesting use-case-based approach to this, see this page. The Subversion command-line client could be extended to provide similar mechanisms when doing interactive conflict resolution during update and merge, and during 'svn resolve'. Ideas for approaches other than the one taken by Subclipse are also welcome and can be discussed.
For a bit of background on tree conflicts, see the section Dealing with Structural Conflicts in the svnbook.
For additional ideas about tree conflict resolution, see notes/tree-conflicts/resolution.txt in the Subversion source tree (note that this text may be partly out of date, consult Julian for updates).
Currently, 'svn commit' cannot commit changes that are located in two or more disconnected working copies (lacking a common parent), even if those working copies belong to the same repository. This is a fairly common need for users that work on multiple projects that are all stored in the same repository and need to commit the changes for multiple projects in a single atomic commit transaction.
There are several issues in the issue tracker that describe the problem in more detail (see issue #2381).
Subversion's authorization model mostly does the job it was designed to do, but is in some ways overprotective to the point of unnecessary loss of functionality. Issue #3380 tracks the overhaul of the model.
Subversion currently supports some mechanisms for selectively building and populating a working copy, including sparse directory support and externals definitions. What Subversion lacks is a handy way to be told — in one easy step — to go off and make use of those underlying features to build a working copy that looks some specific way. Imagine being able to tell new developers on your project to checkout a working copy using some pre-formulated specification which results in an automated sparse checkout that includes your trunk, branches, and then various branches for the currently maintained versions of your software (branches/SOME-VERSION), instead of having to tell them to first do a --depth=empty checkout of the root, then a --set-depth=infinity update of trunk and branches, then ….
Subversion's filesystem backends (BDB and FSFS) currently store in the nodes of the DAG representation of the versioned filesystem predecessor references, so for any given node (identified by path and revision number), you can ask the question, "Which node represents the previous version of this file or directory?" What you cannot ask today is, "Which node(s) represent the next version(s) of this file or directory?" (There can be multiple answers because a given node can be succeeded both by making typical versioned changes to that file/directory and by copying it elsewhere (via svn copy, e.g.).) Making the predecessor/successor linkage bi-directional could be crucial to allowing users to answer questions like, "Now that I've fixed this bug that was introduced into SOME-FILE at revision REV, to what other branches was this version of the file copied (so I can fix the bug in those places, too)?"
Some work for the Berkeley DB backend was done long ago, and lives today in the fs-successor-ids branch.
Subversion has great new Python bindings, written using ctypes, but they are not yet used by any major projects. This summer of code project involves integrating the ctypes python bindings into Trac.
This project will consist of the following tasks:
Students accepted for this task will be granted a branch in the Subversion repository for development of related changes, and will be expected to commit at least one change or status update per week until the project is complete.
For questions about this project (or feedback on planned proposals), please email dev@subversion.tigris.org and CC David James, who has volunteered to mentor ctypes python bindings projects.
These are non-coding tasks, so they are NOT eligible for Google Summer of Code. If you have come here from the Summer of Code pages, skip this section of the page.
Do we need an Issue Manager? Maybe...
The Subversion bug database has been managed in a rather ad hoc fashion thus far. Periodically we make sweeps over all outstanding issues and try to prioritize them, organize them into scheduled milestones, note dependencies between issues, etc. These methods have been moderately successful up till now, but they are not scaling well as the number of issues grows. Since issue growth is proportional to user base growth, the issue tracker is becoming a victim of Subversion's success. We need to find new ways of managing our issues, ways that do not involve making O(N) sweeps over the entire list of open issues at regular intervals.
While we have some semi-formalized management roles (patch manager, release manager, etc), we have never had an issue manager. It might be time to get one, though. It's not yet clear whether the problem is mainly one of attention, or of algorithm, or both, but having someone dedicated to managing the issues database couldn't hurt. One thing such a person could do would be to go through the list of outstanding issues, figure out which ones are likely to be bite-sized tasks, and mark them as such, so that other volunteers have an easier time choosing things to work on. We've already marked various issues as bite-sized, but we haven't done so consistently as new issues come in. This means there are a lot of potential entry points to the project going unnoticed. Want to help us solve that?
Creative ideas welcome! If you'd like to help with this, please subscribe to the dev@subversion.tigris.org mailing list and post your thoughts.
We need a FAQ manager. A FAQ manager is someone who stays subscribed to the users@subversion.tigris.org and dev@subversion.tigris.org mailing lists, watches for common questions or addenda to existing questions, and slowly adjusts the Subversion FAQ in response to the problems users are having "in the wild". This is also a great way to get familiar with Subversion usage patterns and common problems. If you use or administrate Subversion anyway, helping to manage the FAQ is a great way to expand your troubleshooting skills.
Again, creative ideas are most welcome. Please post to the dev@subversion.tigris.org mailing list if you're interested in this.
The Subversion bug database contains many issues classified as "bite-sized" tasks — tasks that are well-defined and self-contained, and thus suitable for a volunteer looking to get involved with the project. You don't need broad or detailed knowledge of Subversion's design to take on one of these, just a pretty good idea of how things generally work, and familiarity with the coding guidelines in the Hacker's Guide to Subversion. Many tasks are things a volunteer could pick off in a spare week or two, and they're a great way to start learning your way around the Subversion code.
If you start one of these tasks, please notify the other developers by marking the issue as "STARTED" in the issue tracker, then mail dev@subversion.tigris.org (subscribe to that list too) with questions. Don't be shy, it's a very civil mailing list.
When you're ready to send in a patch, see the patch posting guidelines. Don't be discouraged if your patch goes through several iterations of review by other developers; this is normal.
Here is the list of all bite-sized tasks.
The tasks listed below are bigger than bite-sized, but probably don't require new research to solve. In other words, most of them are a Simple Matter Of Programming. You'd need to either be, or be willing to become, familiar with Subversion's internals to solve one of these.
As with the bite-sized tasks, please read the Hacker's Guide to Subversion and don't hesitate to ask questions on the users@subversion.tigris.org and dev@subversion.tigris.org mailing lists (see here for subscription information). Before posting any patches, see the patch posting guidelines.
For groups of tasks tied to specific releases, peruse the status page. For a longer-term view of Subversion's vision, see the road map.
Too many of Subversion's error messages are terse or confusing. Many instances are recorded in issue #1254, but see also issues #2302, #2295, and #2275.
One of Subversion's strengths is that it offers a rich set of "binding surfaces": well-documented APIs that are available not only in C (Subversion's native language) but in other programming languages as well (see the complete list).
Some of these language bindings are maintained via SWIG, a tool that partially automates the process of generating bindings, while others are maintained by hand. Many of the bindings do not have complete coverage yet, or have interface problems where they do have coverage. So even though they're used in many production systems, there's still plenty of work to do. Specifically:
The SWIG/Python bindings are in pretty good shape, but their coverage is not yet complete. Help is welcome.
Our Java, SWIG/Perl, and SWIG/Ruby bindings are in pretty good shape, but maybe there are other languages you'd like to call Subversion APIs from? Lisp/Scheme? Feel free to start a new bindings project, if you don't see what you need here.
You want to see the complete list of open bugs, in all its glory? Don't say we didn't warn you...