[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Questions about this GSOC

From: Stefan Sperling <stsp_at_elego.de>
Date: Fri, 18 Mar 2011 20:43:20 +0100

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

This is an archived mail posted to the Subversion Dev mailing list.