www/project_tasks.html - subversion - Git at Google

 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml">
 <head>
 <style type="text/css"> /* <![CDATA[ */
   @import "branding/css/tigris.css";
   @import "branding/css/inst.css";
   /* ]]> */</style>
 <link rel="stylesheet" type="text/css" media="print"
   href="branding/css/print.css"/>
 <script type="text/javascript" src="branding/scripts/tigris.js"></script>
 <title>What Needs Doing?</title>
 </head>

 <body>
 <div class="app">

 <h1 style="text-align: center;">What Needs Doing?</h1>

 <p>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.</p>

 <p>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&nbsp;&mdash;&nbsp;and then fill it.</p>

 <!-- ============================================================= -->
 <div class="h2" id="summer-of-code" title="summer-of-code">
 <h2>Summer of Code Tasks</h2>

 <p>These are the ideas that the Subversion developers have for Summer
 of Code applicants.  As the above states, don't take these as
 gospel!  We welcome discussion on creative proposals.</p>

 <p>However, please don't select tasks in the other sections of this
 page as your proposal, as these are either not the right size for the
 Summer of Code, or are downright not coding tasks, and therefore not
 eligible in any case.</p>

 <p>You should also read the <a href="hacking.html">Hacker's Guide to
 Subversion</a> before starting out on a proposal. Don't hesitate to
 ask for details or start discussing one of these tasks on the <a
 href="mailto:dev@subversion.tigris.org">dev@subversion.tigris.org</a>
 mailing list (see <a
 href="http://subversion.tigris.org/servlets/ProjectMailingListList"
 >here</a> for subscription information).</p>

 <p><b>In fact, please do discuss your task on the mailing list:
 regardless of whether you start discussing before or after submitting your
 application, a demonstrated willingness to engage with the rest of the
 Subversion development community will be considered favourable in evaluating
 your application!</b></p>

 <div class="h3" id="svnserve-logging" title="svnserve-logging">
 <h3><a href="http://subversion.tigris.org/issues/show_bug.cgi?id=2409"
 >Issue&nbsp;#2409</a>: Operation and error logging for svnserve</h3>

 <p>Subversion 1.3.0 added support for operational logging in
 mod_dav_svn.  That is, logging what actual client-side operations are
 performed on a repository, rather than just logging the endless flow
 of WebDAV requests.  Support for this kind of logging, as well as
 error logging, needs to be added to the standalone svnserve daemon.
 This requires some work in the APR library, which would provide the
 actual logging facility.</p>

 <p>This has been extensively discussed on the Subversion development
 mailing list in the past.  A good first step would be to review the
 previous proposals.</p>

 </div>

 <div class="h3" id="python-bindings" title="python-bindings">
 <h3>Improving the Python bindings</h3>

 <p>The Subversion Python bindings are currently incomplete in the
 functionality that they expose.  Furthermore, the Python bindings are
 currently extremely unpythonic in their structure, and could do with a layer
 of python code to make them so.  The bindings should first be brought up to date
 and all functionnalities completely implemented, and second be wrapped in a
 set of Python classes implementing an interface more friendly to
 python developers.</p>

 </div>


 <div class="h3" id="functional-tests" title="functional-tests">
 <h3>Rewriting Subversion's Functional Test Suite</h3>

 <p>Subversion has a number of C language unit-tests for its library
 APIs, but it has a far more extensive set of black-box functional
 tests that simply drive the svn client and examine the results.  This
 functional test suite is written in python, and involves some complex
 parsing of the client's output into trees.</p>

 <p>While the test suite started out with an elegant design, it grew
 "organically" as Subversion (and its behaviors and output) evolved,
 and now has a number of problems:</p>

 <ul>

 <li>It has datastructures with deprecated fields that are now padded,
 and strange quirky parsing algorithms that are more complex than
 necessary.</li>

 <li>The API for creating new tests is overly complex, fragile, and not
 intuitive at all for new users.  It should be easy (not intimidating!)
 to create a new test.  (At the moment, people write new tests by
 copying an existing one, tweaking it, and praying it works.)</li>

 <li>It should integrate with python's existing <tt>unittest</tt> framework</li>

 </ul>

 <p>In a nutshell, this is an all-summer task that boils down to
 redesigning the existing test framework, and rewriting all existing
 tests.  For more info about the design of our current testing
 framework, read <a
 href="http://svn.collab.net/repos/svn/trunk/subversion/tests/README">this
 README</a> and <a
 href="http://svn.collab.net/repos/svn/trunk/subversion/tests/cmdline/svntest/tree.py">the
 comments in this file</a>.</p>

 </div>


 <div class="h3" id="dav-performance-analysis" title="dav-performance-analysis">
 <h3>Performance analysis tool for mod_dav_svn</h3>

 <p>In order to drive future development, we would like to know just
 how much a Subversion mod_dav_svn server can be pushed, and what
 capacity administrators can expect when deploying their Subversion servers.
 One option is to use the <a href="http://httpd.apache.org/test/flood/"
 >Apache Flood</a> load tester.  Test profiles will need to be written to
 simulate usual repository use across multiple users.  Then, load testing
 needs to be conducted with the help of various profiling tools
 (<a href="http://oprofile.sourceforge.net/">oprofile</a>,
 <a href="http://www.opensolaris.org/os/community/dtrace/">dtrace</a>...)
 to identify the current limits and bottlenecks of Subversion.  Bottlenecks
 may be in <a href="http://httpd.apache.org/">Apache HTTP Server</a>,
 <a href="http://apr.apache.org/">APR</a>, mod_dav_svn (Subversion's Apache
 module), our repository backends (FSFS or BDB), or even the underlying
 operating system.</p>

 <p>The final output of this task should be pretty graphs, explanations
 behind the graphs, tuning recommendations, and proposals to improve the
 performance of Subversion.  Time permitting, some or all of these proposals
 would be fleshed out and implemented.</p>

 </div>


 <div class="h3" id="svn-augmented-diff" title="svn-augmented-diff">
 <h3>An augmented diff representation</h3>

 <p>Currently, 'svn diff' outputs a patch in the so-called "Unified
 diff" format.  The problem is, this format is fairly old, and as such
 can represent only textual differences between files.  It does not
 represent structural changes to the directory tree, nor can it
 encompass changes to various metadata, the kind used extremely
 frequently by Subversion.</p>

 <p>'svn diff' actually has two or three use cases.  The first is to
 produce a human-reviewable description of a change suitable for code
 review.  The second (and maybe third) are to produce a file that can
 be sent by email or stored somewhere for later application, by patch(1)
 (the second use case) or some other more-capable patch tool (the third
 use case).  Of these, 'svn diff' currently only supports the first case.
 For example, copied files are currently shown as differences against the
 original version of the file, which makes review easier, though isn't
 suitable for applying with patch.</p>

 <p>This task is: First, to propose a solution for serialising a complete
 representation of a change.  Then, implement that solution with a new
 switch to 'svn diff' and a new subcommand ('svn patch'?) that would
 apply a previously created serialised patch.</p>

 <p>Things to consider in your design of the serialisation format:</p>
 <ul>
 <li>Whether it represents content diffs in a human-readable format
 (probably using the unified diff format), Subversion's native binary
 delta format, or some other format.  Considerations include non-precise
 (fuzzy) patching and representing changes to binary files.</li>
 <li>Whether it should be compatible (to some degree) with patch(1)
 (by encoding extra information in a "garbage" chunk of data that patch
 will ignore, similar to the way property changes are reported today).</li>
 <li>How renames (when eventually implemented as a primitive operation)
 should be represented.</li>
 </ul>

 <p>Note that <a href="http://svk.elixus.org">SVK</a> posesses such a
 rich unified diff format.  It may or may not be desirable to reuse the
 same kind of representation; that decision is part of the task!</p>

 </div>


 <div class="h3" id="svn-commit" title="svn-commit">
 <h3>Allow Commit from multiple working copies</h3>

 <p>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.</p>

 <p>There are at several issues in the issue tracker that describe the
 problem in more detail (see <a
 href="http://subversion.tigris.org/issues/show_bug.cgi?id=2381">issue
 #2381</a>).</p>

 </div>


 </div>

 <!-- ============================================================= -->
 <div class="h2" id="information-management" title="information-management">
 <h2>Information Management Tasks</h2>

 <p>These are non-coding tasks, so they are <b>NOT</b> eligible for
 <a href="http://code.google.com/summerofcode.html">Google Summer of Code</a>.
 If you have come here from the Summer of Code pages, skip this section of the
 page.</p>

 <div class="h3" id="issue-management" title="issue-management">
 <h3>Issue Management</h3>

 <p>Do we need an Issue Manager?  Maybe...</p>

 <p>The Subversion <a
 href="http://subversion.tigris.org/project_issues.html">bug
 database</a> 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.</p>

 <p>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 <a
 href="#bite-sized">bite-sized tasks</a>, 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?</p>

 <p>Creative ideas welcome!  If you'd like to help with this, please <a
 href="http://subversion.tigris.org/servlets/ProjectMailingListList"
 >subscribe</a> to the <a
 href="mailto:dev@subversion.tigris.org">dev@subversion.tigris.org</a>
 mailing list and post your thoughts.</p>

 </div>

 <div class="h3" id="faq-management" title="faq-management">
 <h3>FAQ Management</h3>

 <p>We need a FAQ manager.  A FAQ manager is someone who stays
 subscribed to the <a
 href="mailto:users@subversion.tigris.org">users@subversion.tigris.org</a>
 and <a href="mailto:dev@subversion.tigris.org"
 >dev@subversion.tigris.org</a> mailing lists, watches for common
 questions or addenda to existing questions, and slowly adjusts the
 Subversion <a href="faq.html">FAQ</a> 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.</p>

 <p>Again, creative ideas are most welcome.  Please post to the <a
 href="mailto:dev@subversion.tigris.org">dev@subversion.tigris.org</a>
 mailing list if you're interested in this.</p>

 </div>

 </div>

 <!-- ============================================================= -->
 <div class="h2" id="bite-sized" title="bite-sized">
 <h2>Bite-Sized Coding Tasks</h2>

 <p>The Subversion bug database contains many issues classified as
 "bite-sized" tasks&nbsp;&mdash;&nbsp;tasks that are well-defined and
 self-contained, and thus suitable for a volunteer looking to get
 involved with the project.  You <i>don't</i> 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
 <a href="hacking.html">Hacker's Guide to Subversion</a>.  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.</p>

 <p> If you start one of these tasks, please notify the other
 developers by marking the issue as "STARTED" in the issue tracker,
 then mail <a
 href="mailto:dev@subversion.tigris.org">dev@subversion.tigris.org</a>
 (<a
 href="http://subversion.tigris.org/servlets/ProjectMailingListList"
 >subscribe</a> to that list too) with questions.  Don't be shy, it's a
 very civil mailing list.</p>

 <p>When you're ready to send in a patch, see the <a
 href="http://subversion.tigris.org/mailing-list-guidelines.html#patches"
 >patch posting guidelines</a>.  Don't be discouraged if your patch
 goes through several iterations of review by other developers; this is
 normal.</p>

 <p>Here is the <a
 href="http://subversion.tigris.org/issues/buglist.cgi?component=subversion&amp;issue_status=UNCONFIRMED&amp;issue_status=NEW&amp;issue_status=STARTED&amp;issue_status=REOPENED&amp;keywords=bite-sized&amp;cmdtype=doit"
 >list of all bite-sized tasks</a>.</p>

 </div>

 <!-- ============================================================= -->
 <div class="h2" id="larger-tasks" title="larger-tasks">
 <h2>Larger (But Not Necessarily Huge) Coding Tasks</h2>

 <p>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 <a href="http://www.catb.org/~esr/jargon/html/S/SMOP.html">Simple
 Matter Of Programming</a>.  You'd need to either be, or be willing to
 become, familiar with Subversion's internals to solve one of
 these.</p>

 <p>As with the <a href="#bite-sized">bite-sized tasks</a>, please read
 the
 <a href="hacking.html">Hacker's Guide to Subversion</a> and don't
 hesitate to ask questions on the
 <a href="mailto:users@subversion.tigris.org">users@subversion.tigris.org</a>
 and
 <a href="mailto:dev@subversion.tigris.org">dev@subversion.tigris.org</a>
 mailing lists (see <a
 href="http://subversion.tigris.org/servlets/ProjectMailingListList"
 >here</a> for subscription information).  Before posting any patches,
 see the <a
 href="http://subversion.tigris.org/mailing-list-guidelines.html#patches"
 >patch posting guidelines</a>.</p>

 <p>For <a href="project_status.html#upcoming">groups of tasks tied to
 specific releases</a>, peruse the <a href="project_status.html">status
 page</a>.  For a longer-term view of Subversion's vision, see the <a
 href="roadmap.html">road map</a>.</p>

 <div class="h3" id="error-messages" title="error-messages">
 <h3><a href="http://subversion.tigris.org/issues/show_bug.cgi?id=1254"
 >Issue&nbsp;#1254</a>, etc: Improve error messages</h3>

 <p>Too many of Subversion's error messages are terse or confusing.
 Many instances are recorded in
 <a href="http://subversion.tigris.org/issues/show_bug.cgi?id=1254"
 >issue&nbsp;#1254</a>, but see also issues
 <a href="http://subversion.tigris.org/issues/show_bug.cgi?id=2302"
 >#2302</a>,
 <a href="http://subversion.tigris.org/issues/show_bug.cgi?id=2295"
 >#2295</a>, and
 <a href="http://subversion.tigris.org/issues/show_bug.cgi?id=2275"
 >#2275</a>.</p>

 </div>

 </div>

 <!-- ============================================================= -->
 <div class="h2" id="bindings" title="bindings">
 <h2>Improved Bindings to Other Languages</h2>

 <p>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 <a
  href="links.html#lang_bindings">complete list</a>).</p>

 <p>Some of these language bindings are maintained via <a
 href="http://www.swig.org/">SWIG</a>, 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:</p>

 <ul>

 <li><p>The <a
 href="http://svn.collab.net/repos/svn/trunk/subversion/bindings/swig/python/"
 >SWIG/Python bindings</a> are in pretty good shape, but their coverage
 is not yet complete.  Help is welcome.</p></li>

 <li><p>Our <a
 href="http://svn.collab.net/repos/svn/trunk/subversion/bindings/java/javahl/"
 >Java</a>, <a
 href="http://svn.collab.net/repos/svn/trunk/subversion/bindings/swig/perl/"
 >SWIG/Perl</a>, and <a
 href="http://svn.collab.net/repos/svn/trunk/subversion/bindings/swig/ruby/"
 >SWIG/Ruby</a> 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.</p></li>

 </ul>

 </div>

 <!-- ============================================================= -->
 <div class="h2" id="all-issues" title="all-issues">
 <h2>All Open Issues</h2>

 <p>You want to see the complete list of open bugs, in all its glory?
 Don't say we didn't <a
 href="http://subversion.tigris.org/issues/buglist.cgi?component=subversion&amp;issue_status=UNCONFIRMED&amp;issue_status=NEW&amp;issue_status=STARTED&amp;issue_status=REOPENED&amp;order=issues.target_milestone%2C%20issues.priority%2C%20issues.issue_type">warn you...</a></p>

 </div>

 </div>
 </body>
 </html>
	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
	<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
	<style type="text/css"> /* <![CDATA[ */
	@import "branding/css/tigris.css";
	@import "branding/css/inst.css";
	/* ]]> */</style>
	<link rel="stylesheet" type="text/css" media="print"
	href="branding/css/print.css"/>
	<script type="text/javascript" src="branding/scripts/tigris.js"></script>
	<title>What Needs Doing?</title>
	</head>

	<body>
	<div class="app">

	<h1 style="text-align: center;">What Needs Doing?</h1>

	<p>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.</p>

	<p>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.</p>

	<!-- ============================================================= -->
	<div class="h2" id="summer-of-code" title="summer-of-code">
	<h2>Summer of Code Tasks</h2>

	<p>These are the ideas that the Subversion developers have for Summer
	of Code applicants. As the above states, don't take these as
	gospel! We welcome discussion on creative proposals.</p>

	<p>However, please don't select tasks in the other sections of this
	page as your proposal, as these are either not the right size for the
	Summer of Code, or are downright not coding tasks, and therefore not
	eligible in any case.</p>

	<p>You should also read the <a href="hacking.html">Hacker's Guide to
	Subversion</a> before starting out on a proposal. Don't hesitate to
	ask for details or start discussing one of these tasks on the <a
	href="mailto:dev@subversion.tigris.org">dev@subversion.tigris.org</a>
	mailing list (see <a
	href="http://subversion.tigris.org/servlets/ProjectMailingListList"
	>here</a> for subscription information).</p>

	<p><b>In fact, please do discuss your task on the mailing list:
	regardless of whether you start discussing before or after submitting your
	application, a demonstrated willingness to engage with the rest of the
	Subversion development community will be considered favourable in evaluating
	your application!</b></p>

	<div class="h3" id="svnserve-logging" title="svnserve-logging">
	<h3><a href="http://subversion.tigris.org/issues/show_bug.cgi?id=2409"
	>Issue #2409</a>: Operation and error logging for svnserve</h3>

	<p>Subversion 1.3.0 added support for operational logging in
	mod_dav_svn. That is, logging what actual client-side operations are
	performed on a repository, rather than just logging the endless flow
	of WebDAV requests. Support for this kind of logging, as well as
	error logging, needs to be added to the standalone svnserve daemon.
	This requires some work in the APR library, which would provide the
	actual logging facility.</p>

	<p>This has been extensively discussed on the Subversion development
	mailing list in the past. A good first step would be to review the
	previous proposals.</p>

	</div>

	<div class="h3" id="python-bindings" title="python-bindings">
	<h3>Improving the Python bindings</h3>

	<p>The Subversion Python bindings are currently incomplete in the
	functionality that they expose. Furthermore, the Python bindings are
	currently extremely unpythonic in their structure, and could do with a layer
	of python code to make them so. The bindings should first be brought up to date
	and all functionnalities completely implemented, and second be wrapped in a
	set of Python classes implementing an interface more friendly to
	python developers.</p>

	</div>


	<div class="h3" id="functional-tests" title="functional-tests">
	<h3>Rewriting Subversion's Functional Test Suite</h3>

	<p>Subversion has a number of C language unit-tests for its library
	APIs, but it has a far more extensive set of black-box functional
	tests that simply drive the svn client and examine the results. This
	functional test suite is written in python, and involves some complex
	parsing of the client's output into trees.</p>

	<p>While the test suite started out with an elegant design, it grew
	"organically" as Subversion (and its behaviors and output) evolved,
	and now has a number of problems:</p>

	<ul>

	<li>It has datastructures with deprecated fields that are now padded,
	and strange quirky parsing algorithms that are more complex than
	necessary.</li>

	<li>The API for creating new tests is overly complex, fragile, and not
	intuitive at all for new users. It should be easy (not intimidating!)
	to create a new test. (At the moment, people write new tests by
	copying an existing one, tweaking it, and praying it works.)</li>

	<li>It should integrate with python's existing <tt>unittest</tt> framework</li>

	</ul>

	<p>In a nutshell, this is an all-summer task that boils down to
	redesigning the existing test framework, and rewriting all existing
	tests. For more info about the design of our current testing
	framework, read <a
	href="http://svn.collab.net/repos/svn/trunk/subversion/tests/README">this
	README</a> and <a
	href="http://svn.collab.net/repos/svn/trunk/subversion/tests/cmdline/svntest/tree.py">the
	comments in this file</a>.</p>

	</div>


	<div class="h3" id="dav-performance-analysis" title="dav-performance-analysis">
	<h3>Performance analysis tool for mod_dav_svn</h3>

	<p>In order to drive future development, we would like to know just
	how much a Subversion mod_dav_svn server can be pushed, and what
	capacity administrators can expect when deploying their Subversion servers.
	One option is to use the <a href="http://httpd.apache.org/test/flood/"
	>Apache Flood</a> load tester. Test profiles will need to be written to
	simulate usual repository use across multiple users. Then, load testing
	needs to be conducted with the help of various profiling tools
	(<a href="http://oprofile.sourceforge.net/">oprofile</a>,
	<a href="http://www.opensolaris.org/os/community/dtrace/">dtrace</a>...)
	to identify the current limits and bottlenecks of Subversion. Bottlenecks
	may be in <a href="http://httpd.apache.org/">Apache HTTP Server</a>,
	<a href="http://apr.apache.org/">APR</a>, mod_dav_svn (Subversion's Apache
	module), our repository backends (FSFS or BDB), or even the underlying
	operating system.</p>

	<p>The final output of this task should be pretty graphs, explanations
	behind the graphs, tuning recommendations, and proposals to improve the
	performance of Subversion. Time permitting, some or all of these proposals
	would be fleshed out and implemented.</p>

	</div>


	<div class="h3" id="svn-augmented-diff" title="svn-augmented-diff">
	<h3>An augmented diff representation</h3>

	<p>Currently, 'svn diff' outputs a patch in the so-called "Unified
	diff" format. The problem is, this format is fairly old, and as such
	can represent only textual differences between files. It does not
	represent structural changes to the directory tree, nor can it
	encompass changes to various metadata, the kind used extremely
	frequently by Subversion.</p>

	<p>'svn diff' actually has two or three use cases. The first is to
	produce a human-reviewable description of a change suitable for code
	review. The second (and maybe third) are to produce a file that can
	be sent by email or stored somewhere for later application, by patch(1)
	(the second use case) or some other more-capable patch tool (the third
	use case). Of these, 'svn diff' currently only supports the first case.
	For example, copied files are currently shown as differences against the
	original version of the file, which makes review easier, though isn't
	suitable for applying with patch.</p>

	<p>This task is: First, to propose a solution for serialising a complete
	representation of a change. Then, implement that solution with a new
	switch to 'svn diff' and a new subcommand ('svn patch'?) that would
	apply a previously created serialised patch.</p>

	<p>Things to consider in your design of the serialisation format:</p>
	<ul>
	<li>Whether it represents content diffs in a human-readable format
	(probably using the unified diff format), Subversion's native binary
	delta format, or some other format. Considerations include non-precise
	(fuzzy) patching and representing changes to binary files.</li>
	<li>Whether it should be compatible (to some degree) with patch(1)
	(by encoding extra information in a "garbage" chunk of data that patch
	will ignore, similar to the way property changes are reported today).</li>
	<li>How renames (when eventually implemented as a primitive operation)
	should be represented.</li>
	</ul>

	<p>Note that <a href="http://svk.elixus.org">SVK</a> posesses such a
	rich unified diff format. It may or may not be desirable to reuse the
	same kind of representation; that decision is part of the task!</p>

	</div>


	<div class="h3" id="svn-commit" title="svn-commit">
	<h3>Allow Commit from multiple working copies</h3>

	<p>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.</p>

	<p>There are at several issues in the issue tracker that describe the
	problem in more detail (see <a
	href="http://subversion.tigris.org/issues/show_bug.cgi?id=2381">issue
	#2381</a>).</p>

	</div>


	</div>

	<!-- ============================================================= -->
	<div class="h2" id="information-management" title="information-management">
	<h2>Information Management Tasks</h2>

	<p>These are non-coding tasks, so they are <b>NOT</b> eligible for
	<a href="http://code.google.com/summerofcode.html">Google Summer of Code</a>.
	If you have come here from the Summer of Code pages, skip this section of the
	page.</p>

	<div class="h3" id="issue-management" title="issue-management">
	<h3>Issue Management</h3>

	<p>Do we need an Issue Manager? Maybe...</p>

	<p>The Subversion <a
	href="http://subversion.tigris.org/project_issues.html">bug
	database</a> 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.</p>

	<p>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 <a
	href="#bite-sized">bite-sized tasks</a>, 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?</p>

	<p>Creative ideas welcome! If you'd like to help with this, please <a
	href="http://subversion.tigris.org/servlets/ProjectMailingListList"
	>subscribe</a> to the <a
	href="mailto:dev@subversion.tigris.org">dev@subversion.tigris.org</a>
	mailing list and post your thoughts.</p>

	</div>

	<div class="h3" id="faq-management" title="faq-management">
	<h3>FAQ Management</h3>

	<p>We need a FAQ manager. A FAQ manager is someone who stays
	subscribed to the <a
	href="mailto:users@subversion.tigris.org">users@subversion.tigris.org</a>
	and <a href="mailto:dev@subversion.tigris.org"
	>dev@subversion.tigris.org</a> mailing lists, watches for common
	questions or addenda to existing questions, and slowly adjusts the
	Subversion <a href="faq.html">FAQ</a> 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.</p>

	<p>Again, creative ideas are most welcome. Please post to the <a
	href="mailto:dev@subversion.tigris.org">dev@subversion.tigris.org</a>
	mailing list if you're interested in this.</p>

	</div>

	</div>

	<!-- ============================================================= -->
	<div class="h2" id="bite-sized" title="bite-sized">
	<h2>Bite-Sized Coding Tasks</h2>

	<p>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 <i>don't</i> 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
	<a href="hacking.html">Hacker's Guide to Subversion</a>. 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.</p>

	<p> If you start one of these tasks, please notify the other
	developers by marking the issue as "STARTED" in the issue tracker,
	then mail <a
	href="mailto:dev@subversion.tigris.org">dev@subversion.tigris.org</a>
	(<a
	href="http://subversion.tigris.org/servlets/ProjectMailingListList"
	>subscribe</a> to that list too) with questions. Don't be shy, it's a
	very civil mailing list.</p>

	<p>When you're ready to send in a patch, see the <a
	href="http://subversion.tigris.org/mailing-list-guidelines.html#patches"
	>patch posting guidelines</a>. Don't be discouraged if your patch
	goes through several iterations of review by other developers; this is
	normal.</p>

	<p>Here is the <a
	href="http://subversion.tigris.org/issues/buglist.cgi?component=subversion&issue_status=UNCONFIRMED&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&keywords=bite-sized&cmdtype=doit"
	>list of all bite-sized tasks</a>.</p>

	</div>

	<!-- ============================================================= -->
	<div class="h2" id="larger-tasks" title="larger-tasks">
	<h2>Larger (But Not Necessarily Huge) Coding Tasks</h2>

	<p>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 <a href="http://www.catb.org/~esr/jargon/html/S/SMOP.html">Simple
	Matter Of Programming</a>. You'd need to either be, or be willing to
	become, familiar with Subversion's internals to solve one of
	these.</p>

	<p>As with the <a href="#bite-sized">bite-sized tasks</a>, please read
	the
	<a href="hacking.html">Hacker's Guide to Subversion</a> and don't
	hesitate to ask questions on the
	<a href="mailto:users@subversion.tigris.org">users@subversion.tigris.org</a>
	and
	<a href="mailto:dev@subversion.tigris.org">dev@subversion.tigris.org</a>
	mailing lists (see <a
	href="http://subversion.tigris.org/servlets/ProjectMailingListList"
	>here</a> for subscription information). Before posting any patches,
	see the <a
	href="http://subversion.tigris.org/mailing-list-guidelines.html#patches"
	>patch posting guidelines</a>.</p>

	<p>For <a href="project_status.html#upcoming">groups of tasks tied to
	specific releases</a>, peruse the <a href="project_status.html">status
	page</a>. For a longer-term view of Subversion's vision, see the <a
	href="roadmap.html">road map</a>.</p>

	<div class="h3" id="error-messages" title="error-messages">
	<h3><a href="http://subversion.tigris.org/issues/show_bug.cgi?id=1254"
	>Issue #1254</a>, etc: Improve error messages</h3>

	<p>Too many of Subversion's error messages are terse or confusing.
	Many instances are recorded in
	<a href="http://subversion.tigris.org/issues/show_bug.cgi?id=1254"
	>issue #1254</a>, but see also issues
	<a href="http://subversion.tigris.org/issues/show_bug.cgi?id=2302"
	>#2302</a>,
	<a href="http://subversion.tigris.org/issues/show_bug.cgi?id=2295"
	>#2295</a>, and
	<a href="http://subversion.tigris.org/issues/show_bug.cgi?id=2275"
	>#2275</a>.</p>

	</div>

	</div>

	<!-- ============================================================= -->
	<div class="h2" id="bindings" title="bindings">
	<h2>Improved Bindings to Other Languages</h2>

	<p>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 <a
	href="links.html#lang_bindings">complete list</a>).</p>

	<p>Some of these language bindings are maintained via <a
	href="http://www.swig.org/">SWIG</a>, 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:</p>

	<ul>

	<li><p>The <a
	href="http://svn.collab.net/repos/svn/trunk/subversion/bindings/swig/python/"
	>SWIG/Python bindings</a> are in pretty good shape, but their coverage
	is not yet complete. Help is welcome.</p></li>

	<li><p>Our <a
	href="http://svn.collab.net/repos/svn/trunk/subversion/bindings/java/javahl/"
	>Java</a>, <a
	href="http://svn.collab.net/repos/svn/trunk/subversion/bindings/swig/perl/"
	>SWIG/Perl</a>, and <a
	href="http://svn.collab.net/repos/svn/trunk/subversion/bindings/swig/ruby/"
	>SWIG/Ruby</a> 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.</p></li>

	</ul>

	</div>

	<!-- ============================================================= -->
	<div class="h2" id="all-issues" title="all-issues">
	<h2>All Open Issues</h2>

	<p>You want to see the complete list of open bugs, in all its glory?
	Don't say we didn't <a
	href="http://subversion.tigris.org/issues/buglist.cgi?component=subversion&issue_status=UNCONFIRMED&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&order=issues.target_milestone%2C%20issues.priority%2C%20issues.issue_type">warn you...</a></p>

	</div>

	</div>
	</body>
	</html>