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?
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Dec 23, 2014, at 2:40 PM, pd-list-request@lists.iem.at wrote:
From: IOhannes m zmölnig <zmoelnig@iem.at mailto:zmoelnig@iem.at> To: pd-list@lists.iem.at mailto:pd-list@lists.iem.at 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 in a single SVN-root makes things more or less complicated. unlike git, SVN allows you to easily check out a sub-directory and work as if it as a "smaller, more maintainable repo".
things would be different if *the* pd-repo were in git (but it currently is not). while i personally prefer git over SVN, i think it should be upstream's decision which VCS (if any) they want to use.
i think that any packaging/distribution solution that depends on a certain repository format and/or layout, is inherently broken.
fgmards IOhannes
I do get you’re point though, moving forward doesn’t necessarily involve changing a ton of things. At the very least, we can start by getting the externals to build easily for/with Pd vanilla. As I said before, I have a few scripts that do this on Linux already I can look into further.
I just got all excited thinking about how the GIthub approach for OpenFrameworks *really* helped it explode development-wise, but it’s also a relatively young project compared to Pd. I think by “break up the SVN” I’m trying to see if there are some ways to increase ease of access for people who want to step up and maintain an external.
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Dec 23, 2014, at 4:09 PM, Dan Wilcox danomatika@gmail.com wrote:
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?
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Dec 23, 2014, at 2:40 PM, pd-list-request@lists.iem.at mailto:pd-list-request@lists.iem.at wrote:
From: IOhannes m zmölnig <zmoelnig@iem.at mailto:zmoelnig@iem.at> To: pd-list@lists.iem.at mailto:pd-list@lists.iem.at 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 in a single SVN-root makes things more or less complicated. unlike git, SVN allows you to easily check out a sub-directory and work as if it as a "smaller, more maintainable repo".
things would be different if *the* pd-repo were in git (but it currently is not). while i personally prefer git over SVN, i think it should be upstream's decision which VCS (if any) they want to use.
i think that any packaging/distribution solution that depends on a certain repository format and/or layout, is inherently broken.
fgmards IOhannes
On 12/23/2014 10:09 PM, Dan Wilcox wrote:
How many people currently have access to the SVN?
37
Also, doesn’t upstream prefer Git anyway?
who knows. "upstream" for various externals *not* miller. afaik, most upstreams work directly in the SVN (if they still work on the externals). i for myself, would happily move all of my stuff to git (some of my externals already switched and are synched back to svn every now and then)
fgamsr IOhannes
-
Dan Wilcox -
IOhannes m zmölnig