[PD] svn:externals WAS: an easy way to replay a Pd-session (gui)

[Chris McCormick]

Hi Hans,

On Tue, Dec 02, 2008 at 12:41:46PM -0500, Hans-Christoph Steiner wrote:
> I think it's time to have a IRC meeting about this.  How about  
> Thursday?  I am trying to be in #dataflow as much as possible these  
> days, if anyone wants to have an impromptu discussion.

I am happy to meet on IRC, but it will have to be outside work hours for
me here at GMT. Otherwise the weekend is good, but I think maybe this is
something that can be solve on-list. I really think you hit the nail on
the head with this paragraph:

> My question remains, what is the problem we are trying to solve using  
> svn:externals?  If it is to include code that gets built with Pd- 
> extended, then svn:externals doesn't work well for that, just  
> importing releases works much better.  If it is to make a centralized  
> place to find all Pd code, then I wonder if there is a better tool  
> for this, like a special section of SVN for svn:externals outside of  
> trunk or a wiki page.

Can you answer me this: do you see the primary function of Pd public SVN
as supporting pd-extended builds? If this is the case, then we need a
different part of the repository where external writers and abstraction
creators can store their code/patches independent of pd-extended. The
reason we need this is that whilst pd-extended is a wonderful project,
and definately neccessary, not everyone in the Pd world runs it and
probably some people aren't even interested in seeing their work as part
of pd-extended, but they are definately interested in participating in
the development community of Pd. We can't just have a wiki page as that
doesn't suffice for people who want their code versioned inside the
world of Pd code but aren't interested in pd-extended.

What about if SVN was the central place where Pd and related code lives,
and there was a sub-place within that where pd-extended keeps its
source? Most definately snapshots/tags of the former could be copied via
standard svn commands into the latter to make them part of pd-extended
at stable release. This would probably help with co-ordinating and
versioning too. You could tell people "we are coming up for a
pd-extended release, please copy your latest tags into the pd-extended
folder" or do this yourself for code that you maintain. I guess the crux
of what I'm saying is that I don't see the Pd svn trunk as being == to
pd-extended. I see pd-extended as being a part of the ecosystem living
in the svn trunk. I don't think it's fair for one project to be 100% the
boss of trunk. In fact, I find it kind of annoying that once upon a time
I could check out people's code from the svn and compile it
independently, whereas last time I tried I couldn't do it as a bunch of
environment variables weren't set and stuff. I had to hack giant
complicated makefiles just to compile one simple external.

Please excuse me if I've missed anything obvious or said anything
stupid, and feel free to correct me if I am misguided or wrong about the
position of pd-extended in the repository. Maybe it's all just
semantics. But I guess semantics are important in human communities.

Loving the broken paradise, :)

Chris.

-------------------
http://mccormick.cx