Hans-Christoph Steiner wrote:
On Dec 12, 2008, at 3:44 PM, IOhannes m zmölnig wrote:
Chris McCormick wrote:
On Fri, Dec 05, 2008 at 01:06:32AM -0500, Hans-Christoph Steiner wrote:
What about the idea of having a separate section like /pure-data/svn- externals?
hmm, i'm trying (not so) hard to remove the ./abstractions folder in favour of a grand unified ./externals folder...
That will take a lot of political organizing, as we saw before. In the mean time, I don't see much harm in having /pure-data/svn-externals
i am more a fan of gradual migration than of sudden switches. this allows people to adapt changes at their own pace. sometimes it is a bit hard to do (e.g. when migrating from cvs to svn), othertimes it is simpler. if we agree that it might be a good idea to merge ./abstractions and ./externals because all of them contain "external objects" (as explained in your other mail), then i don't see a reason to introduce yet another directory that has to be migrated when the time is nigh.
in some other projects i noticed "packages" which are modules containing both the local code plus dependencies (the latter handled solely via svn:externals)
Using svn:externals for dependencies means that using --ignore-externals would then break.
indeed it does!
the two things are unrelated; i was jus trying to add another viewpoint (though i might have forgotten that i already mentioned that). "packages" in this context meant small packages (e.g. "libraries") rather than te entire shebang.
Do you have an example of such a project?
I am currently using OpenEmbedded a lot for the Reware ARM disk images.
OpenEmbedded tracks hundreds of external projects. It uses git, which has nothing like svn:externals. Instead, the build system, bitbake, which handles downloading the source code to package. If we really want to make a distributed build system, then someone should build it from
i do not oppose to explicitely downloading external dependencies at all. via bitbat or whatever mechanism.
bitbake or some other proven tool, not kludge it with svn:externals.
however to claim that "bitbake" is a 'proven tool' opposed to the 'ugly kludge' "svn:externals" is a bit euphemistic. unless of course you compare all the millions of openembedded developers to the handful of people using subversion.
but anyhow: what do we want to solve with all this "external" stuff (be it pushed into the repo, pulled implicitly or pulled explicitly)? adding new "Pd-libraries" (1st level packages) or build-dependencies (2nd level packages). this 2 might well be handled differently.
fgmsdr IOhannes