[PD] svn:externals

IOhannes m zmoelnig zmoelnig at iem.at
Mon Dec 15 09:28:35 CET 2008


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







More information about the Pd-list mailing list