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

Hans-Christoph Steiner hans at eds.org
Thu Dec 4 06:13:42 CET 2008


On Dec 3, 2008, at 6:19 PM, Chris McCormick wrote:

> 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, :)

I don't think anyone is saying that pure-data SVN == pd-extended,  
plus I don't think anyone is saying that it should be that way.  My  
objection to svn:externals comes from the fact that I have to do a  
lot of annoying work to manage the Pd-extended builds, and so far  
svn:externals has only made that worse.

I don't know about svn --ignore-externals, anyone care to expand on  
that? (yes, I can RTFM, but I am talking real world experience as  
related to Pd, which TFM will not tell me)  What about the idea of  
having a separate section like /pure-data/svn-externals?  If people  
object to having the imported releases in trunk, I can easily manage  
that in the pd-extended branch.

.hc


>
> Chris.
>
> -------------------
> http://mccormick.cx



------------------------------------------------------------------------ 
----

Looking at things from a more basic level, you can come up with a  
more direct solution... It may sound small in theory, but it in  
practice, it can change entire economies.     - Amy Smith






More information about the Pd-list mailing list