You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Gabriela Gibson <ga...@gmail.com> on 2012/12/30 23:31:36 UTC
Proposal for OPW project
Hi,
As you may know, I have been familiarising myself with Subversion
with a view to obtaining an internship under the Outreach Program
for Women. However, I have yet to decide on a project.
For those that aren't aware, this is a 3 month sponsored internship
similar to the Google Summer of Code. Stefan Sperling is acting as a
mentor and has produced an introduction which is available at
http://subversion.apache.org/opw.html. This page includes an outline
of a number of possible projects. My current thought is to work on the
diff project as an intro.
However, in discussion with Stefan, it became clear that I ought to
consult this list before making project decisions. My current feeling
is that I'd like to start with improvements to "svn diff".
Diff Project Proposal
---------------------
Background: by default, the invocation of the external diff command
provides the following arguments:
-u -L README (revision 1426849) -L README (working copy) \
.svn/text-base/README.svn-base /tmp/svn-zuV07j
This breaks down as follows:
-u: default switch. Replaceable by "--extended-command <switches>"
-L: default label switch. Not configurable.
My initial analysis suggests the following changes:
1. Ensure that
svn diff -x ""
or
svn diff --extensions ""
or
Config file property set to:
diff-extensions =
calls a configured external diff command with no "-u" argument.
(as per http://subversion.tigris.org/issues/show_bug.cgi?id=2074)
2. Allow configuration of the "label" argument
Format to be agreed, but for the sake of this discussion, let's say
there is a config property:
diff-label-switch = ...
(As per http://subversion.tigris.org/issues/show_bug.cgi?id=2044)
3. Allow an unlimited number of diff commands to be specified as
follows:
diff-n-cmd = ...
diff-n-mime-type = ...
diff-n-extensions = ...
diff-n-label-switch = ...
This would provide changed behaviour for each mime-type.
---------------------
I'd welcome comments or improvements to this. Have I even understood
the problems correctly?
This feels like a fairly small piece of work. In addition, I plan to
make some small patches for the website (for example, documenting the
setting up Apache so that it displays the web site.
I'm also interested in possible changes to the help system, but I feel
much less confident about this piece.
But this would leave space for other projects. Does anyone have ideas
for good (relatively small) projects to help me learn the code base?
Regards
Gabriela
Re: [PATCH]: Re: Proposal for OPW project
Posted by Branko Čibej <br...@wandisco.com>.
On 03.01.2013 23:27, Gabriela Gibson wrote:
> Change default behaviour of get_deps.sh from downloading gtest
> library to making it an optional target.
>
> * get-deps.sh
> (usage): Add gtest to list of possible arguments.
> (get_deps): Remove gtest from list of default downloads.
>
> Patch by: Gabriela Gibson
Committed in r1428689. Thanks!
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
[PATCH]: Re: Proposal for OPW project
Posted by Gabriela Gibson <ga...@gmail.com>.
On Thu, Jan 03, 2013 at 06:09:33AM +0200, Daniel Shahaf wrote:
>
> Something's missing.
>
> If gtest is a dependency of svn 1.8, you should add it to the usage
> message of the script; if it's not, there's no reason to download it in
> the argc == 1 branch.
I have attached a patch, thank you for the comments.
Re: [PATCH]: Re: Proposal for OPW project
Posted by Branko Čibej <br...@wandisco.com>.
On 03.01.2013 05:09, Daniel Shahaf wrote:
> Gabriela Gibson wrote on Wed, Jan 02, 2013 at 09:21:01 +0000:
>> On 02/01/13 00:55, Branko Čibej wrote:
>>> On 01.01.2013 22:17, Gabriela Gibson wrote:
>>>> Hi Brane and everyone here,
>>>>
>>>> I've used configure and friends before, albeit in a much smaller
>>>> setting, so the territory looks familiar.
>>>>
>>>> Googletest and virtual hosts also looks also like good tools to know
>>>> about -- I'll need some reading-in time, but I'm confident I can take
>>>> this project on. Could you please send me the two test cases and I'll
>>>> have a go?
>>> See:
>>>
>>> subversion/bindings/cxxhl/tests/test_exception.cpp
>>>
>>> A suggestion about dealing with Ggoogle Test: We have to build the GTest
>>> libraries from source with the same compiler options as the rest of the
>>> library, see
>>>
>>> http://code.google.com/p/googletest/wiki/FAQ#Why_is_it_not_recommended_to_install_a_pre-compiled_copy_of_Goog
>>>
>>> On Debian/Ubuntu Linux, "apt-get install libgtest-dev" will put the
>>> sources in /usr/src/gtest and the headers in /usr/include/gtest. I
>>> propose we make our configury do something similar to what we do with
>>> SQLite amalgamation; e.g., get-deps.sh could download and unpack the
>>> GTest sources into ./gtest, and configure could find them there unless
>>> told to look elsewhere.
>>>
>>> Windows will be a bit trickier, but if you can make it work on Linux,
>>> that's quite good enough, so don't worry about Windows at this point.
>>>
>>> -- Brane
>>>
>>>
>> Ok, patch for get-deps.sh attached.
>>
>> I have a question on the compilation process though. Gtest has
>> deprecated autoconf. The remaining options are to use cmake or
>> our own target. Do you agree that a target in the Subversion Makefile
>> is preferred?
>>
>> [[[
>> Changes to get-deps.sh to download gtest
>>
>> * get-deps.sh:
>> (Variable definitions): Adds three "GTEST_*" variables to assist in
>> downloading gtest sources
>> (get_gtest): New function: Download, unzip and move gtest source.
>> (get_deps): Check whether gtest is available
>> Call get_gtest()
>>
>> Patch by: <ga...@gmail.com>
>> ]]]
>> Index: get-deps.sh
>> ===================================================================
>> --- get-deps.sh (revision 1427508)
>> +++ get-deps.sh (working copy)
>> @@ -29,6 +29,9 @@ SERF=serf-1.1.1
>> ZLIB=zlib-1.2.7
>> SQLITE_VERSION=3.7.15.1
>> SQLITE=sqlite-amalgamation-$(printf %d%02d%02d%02d $(echo $SQLITE_VERSION | sed -e 's/\./ /g'))
>> +GTEST_VERSION=1.6.0
>> +GTEST=gtest-${GTEST_VERSION}
>> +GTEST_URL=http://googletest.googlecode.com/files/
>>
>> HTTPD=httpd-2.4.3
>> APR_ICONV=apr-iconv-1.2.1
>> @@ -103,11 +106,23 @@ get_sqlite() {
>>
>> }
>>
>> +get_gtest() {
>> + test -d $BASEDIR/gtest && return
>> +
>> + cd $TEMPDIR
>> + $HTTP_FETCH ${GTEST_URL}/${GTEST}.zip
>> + cd $BASEDIR
>> +
>> + unzip -q $TEMPDIR/$GTEST.zip
>> +
>> + mv $GTEST gtest
>> +}
>> +
>> # main()
>> get_deps() {
>> mkdir -p $TEMPDIR
>>
>> - for i in zlib serf sqlite-amalgamation apr apr-util; do
>> + for i in zlib serf sqlite-amalgamation apr apr-util gtest; do
>> if [ -d $i ]; then
>> echo "Local directory '$i' already exists; the downloaded copy won't be used" >&2
>> fi
>> @@ -126,6 +141,7 @@ get_deps() {
>> get_serf
>> get_zlib
>> get_sqlite
>> + get_gtest
>>
> Something's missing.
>
> If gtest is a dependency of svn 1.8, you should add it to the usage
> message of the script; if it's not, there's no reason to download it in
> the argc == 1 branch.
It's going to become an optional dependency of a non-default build
target. So I agree it shouldn't be downloaded by default. My bad, I
should have reviewed it a bit more before committing.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: [PATCH]: Re: Proposal for OPW project
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Gabriela Gibson wrote on Wed, Jan 02, 2013 at 09:21:01 +0000:
> On 02/01/13 00:55, Branko Čibej wrote:
>> On 01.01.2013 22:17, Gabriela Gibson wrote:
>>> Hi Brane and everyone here,
>>>
>>> I've used configure and friends before, albeit in a much smaller
>>> setting, so the territory looks familiar.
>>>
>>> Googletest and virtual hosts also looks also like good tools to know
>>> about -- I'll need some reading-in time, but I'm confident I can take
>>> this project on. Could you please send me the two test cases and I'll
>>> have a go?
>>
>> See:
>>
>> subversion/bindings/cxxhl/tests/test_exception.cpp
>>
>> A suggestion about dealing with Ggoogle Test: We have to build the GTest
>> libraries from source with the same compiler options as the rest of the
>> library, see
>>
>> http://code.google.com/p/googletest/wiki/FAQ#Why_is_it_not_recommended_to_install_a_pre-compiled_copy_of_Goog
>>
>> On Debian/Ubuntu Linux, "apt-get install libgtest-dev" will put the
>> sources in /usr/src/gtest and the headers in /usr/include/gtest. I
>> propose we make our configury do something similar to what we do with
>> SQLite amalgamation; e.g., get-deps.sh could download and unpack the
>> GTest sources into ./gtest, and configure could find them there unless
>> told to look elsewhere.
>>
>> Windows will be a bit trickier, but if you can make it work on Linux,
>> that's quite good enough, so don't worry about Windows at this point.
>>
>> -- Brane
>>
>>
> Ok, patch for get-deps.sh attached.
>
> I have a question on the compilation process though. Gtest has
> deprecated autoconf. The remaining options are to use cmake or
> our own target. Do you agree that a target in the Subversion Makefile
> is preferred?
>
> [[[
> Changes to get-deps.sh to download gtest
>
> * get-deps.sh:
> (Variable definitions): Adds three "GTEST_*" variables to assist in
> downloading gtest sources
> (get_gtest): New function: Download, unzip and move gtest source.
> (get_deps): Check whether gtest is available
> Call get_gtest()
>
> Patch by: <ga...@gmail.com>
> ]]]
> Index: get-deps.sh
> ===================================================================
> --- get-deps.sh (revision 1427508)
> +++ get-deps.sh (working copy)
> @@ -29,6 +29,9 @@ SERF=serf-1.1.1
> ZLIB=zlib-1.2.7
> SQLITE_VERSION=3.7.15.1
> SQLITE=sqlite-amalgamation-$(printf %d%02d%02d%02d $(echo $SQLITE_VERSION | sed -e 's/\./ /g'))
> +GTEST_VERSION=1.6.0
> +GTEST=gtest-${GTEST_VERSION}
> +GTEST_URL=http://googletest.googlecode.com/files/
>
> HTTPD=httpd-2.4.3
> APR_ICONV=apr-iconv-1.2.1
> @@ -103,11 +106,23 @@ get_sqlite() {
>
> }
>
> +get_gtest() {
> + test -d $BASEDIR/gtest && return
> +
> + cd $TEMPDIR
> + $HTTP_FETCH ${GTEST_URL}/${GTEST}.zip
> + cd $BASEDIR
> +
> + unzip -q $TEMPDIR/$GTEST.zip
> +
> + mv $GTEST gtest
> +}
> +
> # main()
> get_deps() {
> mkdir -p $TEMPDIR
>
> - for i in zlib serf sqlite-amalgamation apr apr-util; do
> + for i in zlib serf sqlite-amalgamation apr apr-util gtest; do
> if [ -d $i ]; then
> echo "Local directory '$i' already exists; the downloaded copy won't be used" >&2
> fi
> @@ -126,6 +141,7 @@ get_deps() {
> get_serf
> get_zlib
> get_sqlite
> + get_gtest
>
Something's missing.
If gtest is a dependency of svn 1.8, you should add it to the usage
message of the script; if it's not, there's no reason to download it in
the argc == 1 branch.
> echo
> echo "If you require mod_dav_svn, the recommended version of httpd is:"
Re: [PATCH]: Re: Proposal for OPW project
Posted by Branko Čibej <br...@wandisco.com>.
On 02.01.2013 10:21, Gabriela Gibson wrote:
> Ok, patch for get-deps.sh attached.
Nice! Committed in r1427728.
I also added gtest to svn:ignore, and made a couple very minor
grammatical fixes in the log message -- adding full-stops to the end of
sentences.
> I have a question on the compilation process though. Gtest has
> deprecated autoconf. The remaining options are to use cmake or
> our own target. Do you agree that a target in the Subversion Makefile
> is preferred?
Given that we do not use cmake, making our own target is the only
reasonable alternative -- remember that we have to use the exact same
compiler and options. Happily that's not so hard, given that gtest is a
very clean build.
Note that you won't be touching Makefile.in at all for that -- the
source of the build configuration is build.conf.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
[PATCH]: Re: Proposal for OPW project
Posted by Gabriela Gibson <ga...@gmail.com>.
On 02/01/13 00:55, Branko Čibej wrote:
> On 01.01.2013 22:17, Gabriela Gibson wrote:
>> Hi Brane and everyone here,
>>
>> I've used configure and friends before, albeit in a much smaller
>> setting, so the territory looks familiar.
>>
>> Googletest and virtual hosts also looks also like good tools to know
>> about -- I'll need some reading-in time, but I'm confident I can take
>> this project on. Could you please send me the two test cases and I'll
>> have a go?
>
> See:
>
> subversion/bindings/cxxhl/tests/test_exception.cpp
>
> A suggestion about dealing with Ggoogle Test: We have to build the GTest
> libraries from source with the same compiler options as the rest of the
> library, see
>
> http://code.google.com/p/googletest/wiki/FAQ#Why_is_it_not_recommended_to_install_a_pre-compiled_copy_of_Goog
>
> On Debian/Ubuntu Linux, "apt-get install libgtest-dev" will put the
> sources in /usr/src/gtest and the headers in /usr/include/gtest. I
> propose we make our configury do something similar to what we do with
> SQLite amalgamation; e.g., get-deps.sh could download and unpack the
> GTest sources into ./gtest, and configure could find them there unless
> told to look elsewhere.
>
> Windows will be a bit trickier, but if you can make it work on Linux,
> that's quite good enough, so don't worry about Windows at this point.
>
> -- Brane
>
>
Ok, patch for get-deps.sh attached.
I have a question on the compilation process though. Gtest has
deprecated autoconf. The remaining options are to use cmake or
our own target. Do you agree that a target in the Subversion Makefile
is preferred?
Re: Proposal for OPW project
Posted by Branko Čibej <br...@wandisco.com>.
On 01.01.2013 22:17, Gabriela Gibson wrote:
> Hi Brane and everyone here,
>
> I've used configure and friends before, albeit in a much smaller
> setting, so the territory looks familiar.
>
> Googletest and virtual hosts also looks also like good tools to know
> about -- I'll need some reading-in time, but I'm confident I can take
> this project on. Could you please send me the two test cases and I'll
> have a go?
See:
subversion/bindings/cxxhl/tests/test_exception.cpp
A suggestion about dealing with Ggoogle Test: We have to build the GTest
libraries from source with the same compiler options as the rest of the
library, see
http://code.google.com/p/googletest/wiki/FAQ#Why_is_it_not_recommended_to_install_a_pre-compiled_copy_of_Goog
On Debian/Ubuntu Linux, "apt-get install libgtest-dev" will put the
sources in /usr/src/gtest and the headers in /usr/include/gtest. I
propose we make our configury do something similar to what we do with
SQLite amalgamation; e.g., get-deps.sh could download and unpack the
GTest sources into ./gtest, and configure could find them there unless
told to look elsewhere.
Windows will be a bit trickier, but if you can make it work on Linux,
that's quite good enough, so don't worry about Windows at this point.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: Proposal for OPW project
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Tue, Jan 1, 2013 at 4:17 PM, Gabriela Gibson
<ga...@gmail.com>wrote:
> The following is a conversation that should have been held on the
> list, please excuse the misunderstanding on my part.
>
No worries - we've all been there before. You'll get the hang of it soon
enough. =) Keep up the posts!
Cheers. -- justin
Re: Proposal for OPW project
Posted by Gabriela Gibson <ga...@gmail.com>.
Hi All,
The following is a conversation that should have been held on the
list, please excuse the misunderstanding on my part.
> On 01.01.2013 15:09, Gabriela Gibson wrote:
> > Hi Brane,
> >
> > Daniel mentioned on the dev list that you are working on the C++
> > bindings and advised me to contact you and ask if you have any
> > suitable projects for me as an OPW intern.
> >
> > SWIG binding was my initial choice of project, but I was advised by
> > Stefan that it might be too difficult at my level of
> > experience/knowledge of the SVN api. Taking his advice, I changed to
> > the diff project at the last minute.
> >
> > However, my selected project is unlikely to keep me occupied for the
> > duration of the internship (I hope!). Daniel thinks that the some of
> > the C++ bindings might be a better entry point to binding work than
> > the SWIG bindings, if suitable projects exist.
> >
> > If you have any entry-level projects that I could get to work on, that
> > would be wonderful.
> >
> > Gabriela
On Tue, Jan 01, 2013 at 03:26:41PM +0100, Branko Čibej wrote:
> Hi Gabriela,
>
> The C++ bindings are in a very, very early stage of development.
> Basically just an idea with a few lines of code. There isn't even a
> design in place that could guide you in selecting which parts to
> implement; it's currently only a foggy notion in my head that we really
> should have a common object model for all the bindings, and that C++ may
> be a good starting point for designing one.
>
> Moreover, in one respect the C++ bindings have the same "problem" as the
> SWIG bindings -- you have to more or less know the whole C API in order
> to even begin designing the wrappers.
>
> There is one area that you may be able to help with, and that's setting
> up a proper test infrastructure for the C++ bindings. I'm planning to
> use Google's C++ test framework for that (see:
> http://code.google.com/p/googletest/). This would involve teaching
> configure and gen-make.py to find the GTest sources (very
> platform-specific) and rewiring the build generator to compile and link
> test programs with the GTest libs. I also have two test cases that could
> be easily converted to GTest.
>
> It's not really much work, but I've been putting it off for lack of
> time. So, if you don't mind digging into the mess that's our build
> system, you're welcome to have a go if you find yourself with enough
> time on your hands. I'll be more than happy to help you find your way
> through the less obvious parts.
>
> -- Brane
>
Hi Brane and everyone here,
I've used configure and friends before, albeit in a much smaller
setting, so the territory looks familiar.
Googletest and virtual hosts also looks also like good tools to know
about -- I'll need some reading-in time, but I'm confident I can take
this project on. Could you please send me the two test cases and I'll
have a go?
regards,
Gabriela
Re: Proposal for OPW project
Posted by Daniel Shahaf <da...@elego.de>.
Gabriela Gibson wrote on Sun, Dec 30, 2012 at 22:31:36 +0000:
> But this would leave space for other projects. Does anyone have ideas
> for good (relatively small) projects to help me learn the code base?
Perhaps pick a library and grep for "###|TODO|FIXME"? Investigating any
one of them (and removing it, or fixing it) will get you familiar with
some part of the code.
Normally I'd have some concrete suggestions too, but fsfs is a moving
target now (being refactored on a feature branch) and I don't recall
offhand what outstanding TODOs related to the new-in-1.8 major features
might be.
I'd also like to suggest bindings work. Extending the C API's available
to the bindings, or otherwise improving the bindings' usability to
programmers, should have plenty of tasks of small-to-medium scale. (In
addition to the swig/java/ctypes bindings, Brane has started work on C++
bindings --- you might ask him if there is a project opportunity for you
there.)
For some bindings the knowledge among devs of the bindings is not very
high, and although someone opined on private it wasn't a suitable entry
project I disagree. It will require working both with our C API and
with the glue API --- that might make it a harder or trickier task, but
I wouldn't rule it out without consideration. (And the C++ bindings,
I expect, don't suffer having an opaque "glue" layer the way some other
bindings do.)
For completeness, svnpubsub has a bunch of TODOs (mostly in Ben and I's
heads), but while it's a supported tool, it's not part of the core
libraries.
HTH
Re: Proposal for OPW project
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Philip Martin wrote on Wed, Jan 02, 2013 at 21:59:59 +0000:
> Gabriela Gibson <ga...@gmail.com> writes:
>
> > On 02/01/13 10:38, Philip Martin wrote:
> >> A small one: svnadmin freeze multiple repositories
> >> http://subversion.tigris.org/issues/show_bug.cgi?id=4276
> >>
> >> A bit larger: rep-cache offset validation
> >> http://subversion.tigris.org/issues/show_bug.cgi?id=4277
> >>
> > The second bug is fs_fs.c territory, so I think I'll wimpy on that
> > for now.
>
> This is is mostly about determining which FSFS function, or perhaps
> sequence of functions, to call. It's probably a smaller patch than the
> freeze patch but perhaps requires more work to understand the FS code.
I believe r1428700 fixed #4277.
Re: Proposal for OPW project
Posted by Gabriela Gibson <ga...@gmail.com>.
On 02/01/13 21:59, Philip Martin wrote:
> Or the loop could go in the libsvn_repos library by changing the
> svn_repos_freeze API to pass an array of paths. The loop in the library
> may well look much like the above svnadmin loop, but putting it in the
> library has the advantage of making it readily available to all clients.
Ok, I will try to do that.
> This is is mostly about determining which FSFS function, or perhaps
> sequence of functions, to call. It's probably a smaller patch than the
> freeze patch but perhaps requires more work to understand the FS code.
>
I'm just trying to keep the 'universe of confusion' as small as possible
for now. Not only have I forgotten a lot in 10 years, a lot also has
changed.
In a month or so, this will be different (I hope), and I will hunt bugs
with a vengeance, but for now, those bugs are actually hunting me!
Re: Proposal for OPW project
Posted by Philip Martin <ph...@wandisco.com>.
Gabriela Gibson <ga...@gmail.com> writes:
> On 02/01/13 10:38, Philip Martin wrote:
>> A small one: svnadmin freeze multiple repositories
>> http://subversion.tigris.org/issues/show_bug.cgi?id=4276
>>
>> A bit larger: rep-cache offset validation
>> http://subversion.tigris.org/issues/show_bug.cgi?id=4277
>>
> The first bug is a keeper, I learn about the command line component
> anyway in the diff project.
The command line stuff is just boilerplate that is needed to get to the
guts of the issue, the main part is putting a loop into the existing
code:
svn_error_t *
freeze_body(...)
{
svn_io_run_cmd(...);
}
svn_error_t *
subcommand_freeze(...)
{
svn_repos_freeze(..., freeze_body, ...);
}
The loop could be a recursive call in svnadmin itself:
svn_error_t *
freeze_body(...)
{
if (repositories)
{
next(repositories);
svn_repos_freeze(..., freeze_body, ...);
}
else
svn_io_run_cmd(...);
}
svn_error_t *
subcommand_freeze(...)
{
svn_repos_freeze(..., freeze_body, ...);
}
Or the loop could go in the libsvn_repos library by changing the
svn_repos_freeze API to pass an array of paths. The loop in the library
may well look much like the above svnadmin loop, but putting it in the
library has the advantage of making it readily available to all clients.
> The second bug is fs_fs.c territory, so I think I'll wimpy on that
> for now.
This is is mostly about determining which FSFS function, or perhaps
sequence of functions, to call. It's probably a smaller patch than the
freeze patch but perhaps requires more work to understand the FS code.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: Proposal for OPW project
Posted by Gabriela Gibson <ga...@gmail.com>.
On 02/01/13 10:38, Philip Martin wrote:
> Gabriela Gibson <ga...@gmail.com> writes:
>
>> But this would leave space for other projects. Does anyone have ideas
>> for good (relatively small) projects to help me learn the code base?
>
> A small one: svnadmin freeze multiple repositories
> http://subversion.tigris.org/issues/show_bug.cgi?id=4276
>
> A bit larger: rep-cache offset validation
> http://subversion.tigris.org/issues/show_bug.cgi?id=4277
>
The first bug is a keeper, I learn about the command line component
anyway in the diff project.
The second bug is fs_fs.c territory, so I think I'll wimpy on that
for now.
So to summarise: I'll offer to do the diff project, the build system
for gtest, and whatever small issues happens to float around involving
commandline work, such as the svnadmin freezing issues or adding test
cases for new-ish bugs.
After I complete those tasks, it's much easier to decide on another,
more involved project.
regards,
Gabriela
Re: Proposal for OPW project
Posted by Philip Martin <ph...@wandisco.com>.
Gabriela Gibson <ga...@gmail.com> writes:
> But this would leave space for other projects. Does anyone have ideas
> for good (relatively small) projects to help me learn the code base?
A small one: svnadmin freeze multiple repositories
http://subversion.tigris.org/issues/show_bug.cgi?id=4276
A bit larger: rep-cache offset validation
http://subversion.tigris.org/issues/show_bug.cgi?id=4277
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download