Maybe it’s more about sourceforge then. Honestly, working with sourceforge is a pain and I haven’t wanted to bother making patches etc for it. Seems like it would be much simpler to fork and do a PR on Github. Also, the suggestion to split up the SVN is based on my experience in the OpenFrameworks community which has clearly proven smaller repos allow for splitting up both the responsibility and work in a maintainable way. It also get rid of all the “who’s maintaining external X” and “what do I have to do to get sourceforge SVN access”. It also helps split up the issues to the individual externals.
Yes, a move like this doesn’t change the nature of how the software works but it helps to expand working on it. You’re in a position with direct access and years of experience working with the current setup. Most of the rest of us aren’t and, from our point of view, the SVN is a monolithic block we’re a little afraid to touch because it seems like it’d be easy to step on people’s toes. How many people currently have access to the SVN?
Also, doesn’t upstream prefer Git anyway?
Date: December 23, 2014 at 1:29:26 PM EST
Subject: Re: [PD] future PD-extended development
On 12/23/2014 03:27 PM, Dan Wilcox wrote:what’s important is to break out the external development from the SVN into smaller, more maintainable repos
i have to admit i totally fail to see, why having all the source code ina single SVN-root makes things more or less complicated.unlike git, SVN allows you to easily check out a sub-directory and workas if it as a "smaller, more maintainable repo".things would be different if *the* pd-repo were in git (but it currentlyis not).while i personally prefer git over SVN, i think it should be upstream'sdecision which VCS (if any) they want to use.i think that any packaging/distribution solution that depends on acertain repository format and/or layout, is inherently broken.fgmardsIOhannes