| blob | f0dd395a1887a02647d1e3211c67171248d63c10 |
4 <head>
13 </head>
15 <body>
20 <p>There are a lot of different things you can do to help Subversion.
21 Not all involve coding; there are plenty of non-programming roles for
22 eager volunteers.</p>
24 <p>Below are some of the needs we've identified, but please don't take
25 these as gospel! New volunteers bring fresh viewpoints, and one of
26 the most important things you can do is point out a need we hadn't
29 <!-- ============================================================= -->
33 <p>These are the ideas that the Subversion developers have for Summer
34 of Code applicants. As the above states, don't take these as
35 gospel! We welcome discussion on creative proposals.</p>
37 <p>However, please don't select tasks in the other sections of this
38 page as your proposal, as these are either not the right size for the
39 Summer of Code, or are downright not coding tasks, and therefore not
40 eligible in any case.</p>
43 Subversion</a> before starting out on a proposal. Don't hesitate to
44 ask for details or start discussing one of these tasks on the <a
46 mailing list (see <a
50 <p><b>In fact, please do discuss your task on the mailing list:
51 regardless of whether you start discussing before or after submitting your
52 application, a demonstrated willingness to engage with the rest of the
53 Subversion development community will be considered favourable in evaluating
54 your application!</b></p>
61 mod_dav_svn. That is, logging what actual client-side operations are
62 performed on a repository, rather than just logging the endless flow
63 of WebDAV requests. Support for this kind of logging, as well as
64 error logging, needs to be added to the standalone svnserve daemon.
65 This requires some work in the APR library, which would provide the
66 actual logging facility.</p>
68 <p>This has been extensively discussed on the Subversion development
69 mailing list in the past. A good first step would be to review the
70 previous proposals.</p>
72 </div>
77 <p>The Subversion Python bindings are currently incomplete in the
78 functionality that they expose. Furthermore, the Python bindings are
79 currently extremely unpythonic in their structure, and could do with a layer
80 of python code to make them so. The bindings should first be brought up to date
81 and all functionnalities completely implemented, and second be wrapped in a
82 set of Python classes implementing an interface more friendly to
83 python developers.</p>
85 </div>
91 <p>Subversion has a number of C language unit-tests for its library
92 APIs, but it has a far more extensive set of black-box functional
93 tests that simply drive the svn client and examine the results. This
94 functional test suite is written in python, and involves some complex
95 parsing of the client's output into trees.</p>
97 <p>While the test suite started out with an elegant design, it grew
98 "organically" as Subversion (and its behaviors and output) evolved,
99 and now has a number of problems:</p>
101 <ul>
103 <li>It has datastructures with deprecated fields that are now padded,
104 and strange quirky parsing algorithms that are more complex than
105 necessary.</li>
107 <li>The API for creating new tests is overly complex, fragile, and not
108 intuitive at all for new users. It should be easy (not intimidating!)
109 to create a new test. (At the moment, people write new tests by
110 copying an existing one, tweaking it, and praying it works.)</li>
114 </ul>
116 <p>In a nutshell, this is an all-summer task that boils down to
117 redesigning the existing test framework, and rewriting all existing
118 tests. For more info about the design of our current testing
119 framework, read <a
125 </div>
131 <p>In order to drive future development, we would like to know just
132 how much a Subversion mod_dav_svn server can be pushed, and what
133 capacity administrators can expect when deploying their Subversion servers.
136 simulate usual repository use across multiple users. Then, load testing
137 needs to be conducted with the help of various profiling tools
140 to identify the current limits and bottlenecks of Subversion. Bottlenecks
143 module), our repository backends (FSFS or BDB), or even the underlying
144 operating system.</p>
146 <p>The final output of this task should be pretty graphs, explanations
147 behind the graphs, tuning recommendations, and proposals to improve the
148 performance of Subversion. Time permitting, some or all of these proposals
149 would be fleshed out and implemented.</p>
151 </div>
158 diff" format. The problem is, this format is fairly old, and as such
159 can represent only textual differences between files. It does not
160 represent structural changes to the directory tree, nor can it
161 encompass changes to various metadata, the kind used extremely
162 frequently by Subversion.</p>
164 <p>'svn diff' actually has two or three use cases. The first is to
165 produce a human-reviewable description of a change suitable for code
166 review. The second (and maybe third) are to produce a file that can
167 be sent by email or stored somewhere for later application, by patch(1)
168 (the second use case) or some other more-capable patch tool (the third
169 use case). Of these, 'svn diff' currently only supports the first case.
170 For example, copied files are currently shown as differences against the
171 original version of the file, which makes review easier, though isn't
172 suitable for applying with patch.</p>
174 <p>This task is: First, to propose a solution for serialising a complete
175 representation of a change. Then, implement that solution with a new
176 switch to 'svn diff' and a new subcommand ('svn patch'?) that would
177 apply a previously created serialised patch.</p>
180 <ul>
181 <li>Whether it represents content diffs in a human-readable format
182 (probably using the unified diff format), Subversion's native binary
183 delta format, or some other format. Considerations include non-precise
184 (fuzzy) patching and representing changes to binary files.</li>
186 (by encoding extra information in a "garbage" chunk of data that patch
187 will ignore, similar to the way property changes are reported today).</li>
188 <li>How renames (when eventually implemented as a primitive operation)
189 should be represented.</li>
190 </ul>
193 rich unified diff format. It may or may not be desirable to reuse the
194 same kind of representation; that decision is part of the task!</p>
196 </div>
202 <p>Currently, 'svn commit' cannot commit changes that are located in
203 two or more disconnected working copies (lacking a common parent),
204 even if those working copies belong to the same repository. This is
205 a fairly common need for users that work on multiple projects that
206 are all stored in the same repository and need to commit the changes
207 for multiple projects in a single atomic commit transaction.</p>
209 <p>There are at several issues in the issue tracker that describe the
210 problem in more detail (see <a
214 </div>
217 </div>
219 <!-- ============================================================= -->
225 If you have come here from the Summer of Code pages, skip this section of the
226 page.</p>
235 database</a> has been managed in a rather ad hoc fashion thus far.
236 Periodically we make sweeps over all outstanding issues and try to
237 prioritize them, organize them into scheduled milestones, note
238 dependencies between issues, etc. These methods have been moderately
239 successful up till now, but they are not scaling well as the number of
240 issues grows. Since issue growth is proportional to user base growth,
241 the issue tracker is becoming a victim of Subversion's success. We
242 need to find new ways of managing our issues, ways that do not involve
243 making O(N) sweeps over the entire list of open issues at regular
244 intervals.</p>
246 <p>While we have some semi-formalized management roles (patch manager,
247 release manager, etc), we have never had an issue manager. It might
248 be time to get one, though. It's not yet clear whether the problem is
249 mainly one of attention, or of algorithm, or both, but having someone
250 dedicated to managing the issues database couldn't hurt. One thing
251 such a person could do would be to go through the list of outstanding
252 issues, figure out which ones are likely to be <a
254 that other volunteers have an easier time choosing things to work on.
255 We've already marked various issues as bite-sized, but we haven't done
256 so consistently as new issues come in. This means there are a lot of
257 potential entry points to the project going unnoticed. Want to help
258 us solve that?</p>
264 mailing list and post your thoughts.</p>
266 </div>
271 <p>We need a FAQ manager. A FAQ manager is someone who stays
272 subscribed to the <a
276 questions or addenda to existing questions, and slowly adjusts the
278 users are having "in the wild". This is also a great way to get
279 familiar with Subversion usage patterns and common problems. If you
280 use or administrate Subversion anyway, helping to manage the FAQ is a
281 great way to expand your troubleshooting skills.</p>
285 mailing list if you're interested in this.</p>
287 </div>
289 </div>
291 <!-- ============================================================= -->
295 <p>The Subversion bug database contains many issues classified as
297 self-contained, and thus suitable for a volunteer looking to get
299 knowledge of Subversion's design to take on one of these, just a
300 pretty good idea of how things generally work, and familiarity with
301 the coding guidelines in the
303 are things a volunteer could pick off in a spare week or two, and
304 they're a great way to start learning your way around the Subversion
305 code.</p>
307 <p> If you start one of these tasks, please notify the other
308 developers by marking the issue as "STARTED" in the issue tracker,
309 then mail <a
311 (<a
314 very civil mailing list.</p>
319 goes through several iterations of review by other developers; this is
320 normal.</p>
323 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"
326 </div>
328 <!-- ============================================================= -->
332 <p>The tasks listed below are bigger than bite-sized, but probably
333 don't require new research to solve. In other words, most of them are
335 Matter Of Programming</a>. You'd need to either be, or be willing to
336 become, familiar with Subversion's internals to solve one of
337 these.</p>
340 the
342 hesitate to ask questions on the
344 and
346 mailing lists (see <a
349 see the <a
362 <p>Too many of Subversion's error messages are terse or confusing.
363 Many instances are recorded in
373 </div>
375 </div>
377 <!-- ============================================================= -->
381 <p>One of Subversion's strengths is that it offers a rich set of
382 "binding surfaces": well-documented APIs that are available not only
383 in C (Subversion's native language) but in other programming languages
384 as well (see the <a
389 the process of generating bindings, while others are maintained by
390 hand. Many of the bindings do not have complete coverage yet, or have
391 interface problems where they do have coverage. So even though
392 they're used in many production systems, there's still plenty of work
393 to do. Specifically:</p>
395 <ul>
400 is not yet complete. Help is welcome.</p></li>
409 other languages you'd like to call Subversion APIs from? Lisp/Scheme?
410 Feel free to start a new bindings project, if you don't see what you
411 need here.</p></li>
413 </ul>
415 </div>
417 <!-- ============================================================= -->
421 <p>You want to see the complete list of open bugs, in all its glory?
422 Don't say we didn't <a
423 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>
425 </div>
427 </div>
428 </body>
429 </html>