On Dec 26, 2007, at 11:19 AM, Russell Bryant wrote:
IOhannes m zmölnig wrote:
the separate externals reflect the separate developments by separate (groups of) people. there is no "official" externals-package that are to be packaged together, even though pd-extended makes it look like this; but pd-extended is "yet another project" that is targetted at a big get-everything package: which is fine from an end-user point-of-view, but not necessarily from a developer's point-of-view.
Yes, I do agree that it makes sense to fit the tool to the desired model of devleopment, and not fit development to the tool ...
my initial arguing was, that for packages (like pd-extended) one could create a bundle (e.g. svn:externals) that aggragates everything needed in another subfolder. back then (search the archives for "svn migration" or similar in 2007-09) the the answer to this was: "we should not beta-test experimental features of svn" (this is what i was alluding to in my first response to this thread)
Ah, ok. Well, in my opinion, svn:externals works great. I have been using it heavily for the past couple of years with various projects and have not had any problems.
I made the "beta-test" comment, I just wanted to know whether it was tried and true before committing to it. I don't really get the advantage of using it. Can you maintain patches against the code that is linked in using svn:externals? A big reason to import the external code is so that you can maintain changes, and to add importing new external releases into those changes. How does that work with svn:externals?
.hc
------------------------------------------------------------------------ ----
kill your television