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.
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