Mailing-List: contact dev-help@community.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@community.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Date: Mon, 22 Mar 2010 13:41:43 +0100
From: Stefan Sperling <stsp@apache.org>
To: dev@community.apache.org
Subject: Gsoc ideas for Subversion
Message-ID: <20100322124143.GD14843@jack.stsp.name>
Mail-Followup-To: dev@community.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.5.20 (2009-06-14)

Hi,

the Subversion project does not use JIRA, so I'm contacting this
list instead. Is posting here all I have to do to get these ideas added?

The following gsoc project ideas exist for Subversion:

= Idea 1 =
Add support for Git/Mercurial style unidiff format extensions
'svn diff' and 'svn patch' should be able to produce and apply
unidiff files containing git-style extensions to the unidiff format.
See http://svn.apache.org/repos/asf/subversion/trunk/notes/svnpatch/svnpatch-git.txt
That would allow us to use patches for tree and mode changes.
Extra brownie points will be given to students expanding upon the
git unidiff extensions by adding support for expressing changes made
to Subversion properties (which can be text and binary data).

= Idea 2 =
Authorization model overhaul
Subversion's authorization model mostly does the job it was designed
to do, but is in some ways overprotective to the point of unnecessary
loss of functionality. Issue #3380 tracks the overhaul of the model.

= Idea 3 =
Viewspecs
Subversion currently supports some mechanisms for selectively building
and populating a working copy, including sparse directory support and
externals definitions. What Subversion lacks is a handy way to be told —
in one easy step — to go off and make use of those underlying features
to build a working copy that looks some specific way. Imagine being able
to tell new developers on your project to checkout a working copy using
some pre-formulated specification which results in an automated sparse
checkout that includes your trunk, branches, and then various branches
for the currently maintained versions of your software
(branches/SOME-VERSION), instead of having to tell them to first do a
--depth=empty checkout of the root, then a --set-depth=infinity update
of trunk and branches, then ….


I would be willing to mentor one student who applies for any of these.
I was already a mentor for Subversion during gsoc 2009.

I hope that more Subversion developers will volunteer to be mentors.
Last year we had three mentors.

Thanks,
Stefan