On Thu, Mar 17, 2011 at 11:35:22PM +0800, yun lee wrote:
> Hi, everyone. Nice to write in the mailing list.
Hi Yun Lee!
> I'm a GSOC student volunteer for SVN.
>
> I have passed last year's GSOC with DERBY as my project. It's my last
> school year and also the 5th year that I use SVN in my developping,
> and I would love to choose SVN for this GSOC.
>
> So far, I have read through "Apache Subversion Community Guide", and
> begun to read the source files recommended in "Code to read".
Great! That's a good start.
> I still have some questions about this GSOC:
>
> 1.Which project ideas will be proposed?
We used to have a list of project ideas on our old site at tigris.org.
That seems to be gone.
Currently, we're mostly working towards the 1.7 release.
But release stabilisation is probably not that good a topic for a gsoc
project.
I have two new ideas:
- Allow the test suite to be run in production environments.
Subversion has a comprehensive regression test suite.
It is possible to run these tests with all repository backends (BDB, FSFS),
and with all repository access protocols (file://, svn://, http://).
The tests create their own repositories, and test data is expected to be
imported at the root of these repositories. This means that it is not
easy to run tests in a production Subversion setup. The tests always
run in a clean-room environment, and there is no comprehensive way
to check how Subversion interacts with an actual production environment.
An organisation that plans to upgrade their Subversion installation may want
to run Subversion's regression test suite on their own Subversion server,
to make sure that things will still work well after the upgrade.
They might want to use an existing repository for test data.
They might even want to add custom tests to the test suite that cover
use cases which are important to them, and possibly contribute their
own tests back to the Subversion project.
Our testsuite cannot be used for this purpose at the moment.
I know of one company that has done this, though. They can run a basic
set of Subversion tests in their own production environment.
They had to make some changes to the test suite to make this work.
But their changes are not ready for integration into the Subversion
project, because they have not been generalised. Maybe their work
could be used as a starting point.
- Improve support for external diff and merge tools.
Subversion's internal diff and merge implementations can only
deal with line-based textual data.
To support more specialized tools (e.g. for merging XML documents or
even binary file formats), Subversion has basic support for external
diff and merge tools. Users can specify externals tools in the
configuration file. But, once configured, these tools will always
get invoked for all types of files.
Users may need to run different diff/merge tools for different kinds
of files. A common approach is to write a wrapper script, which then
invokes and appropriate diff or merge tool based on the filename.
It would be nice if Subversion did not require users to write wrapper
scripts like this.
Various mailing list threads discuss past and present issues
with external diff and merge tools.
Here is a recent one:
http://svn.haxx.se/users/archive-2011-03/0159.shtml
The archive should be searched for more.
There are also a couple of open issues related to this topic:
http://subversion.tigris.org/issues/show_bug.cgi?id=2044
http://subversion.tigris.org/issues/show_bug.cgi?id=2447
http://subversion.tigris.org/issues/show_bug.cgi?id=3836
> 2.How many students will be accepted?
That depends on how many students will apply, and how many slots
will be assigned to the Apache Software Foundation.
> 3.What can I do now to help my application?
You could start submitting patches and get involved with community.
Patches don't have to be related to your gsoc topic of course.
See the community guide for information on how to find out where
we need help :)
http://subversion.apache.org/contributing.html
Received on 2011-03-18 20:43:57 CET