community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: Gsoc ideas for Subversion
Date Tue, 23 Mar 2010 14:52:29 GMT
On 22/03/2010 12:41, Stefan Sperling wrote:
> 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?

In order to get these listed you need to add them to the comdev project 
in JIRA. Please add them to that component with the labels "gsoc" and 
"mentor".

Ensure your title has "Subversion:" at the start (you'll see why in a 
moment).

Your issues will then appear in the list of projects at 
https://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12314021

To create a list of just your projects make a copy of the filter at the 
above URL, narrow down to the comdev project and filter for 
"Subversion:" (I've already done this at 
https://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12314115)

You can then link to this from your own site and access XML, RSS feeds.

In order to test this out I have already added the first of your ideas 
below (see https://issues.apache.org/jira/browse/COMDEV-29) The others 
need adding.

Ross

> 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


Mime
View raw message