[PD] svn:externals

Hans-Christoph Steiner hans at eds.org
Wed Dec 17 00:52:16 CET 2008


On Dec 15, 2008, at 3:28 AM, IOhannes m zmoelnig wrote:

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

How many large integration projects are using svn:externals.  That's  
the real question.  I've worked on a few, like WRT54G firmwares and  
openembedded.  The WRT stuff usually imports the code releases,  
OpenEmbedded has a whole system of downloading the right versions  
with automatic handling of mirrors.

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

I think it is a good idea to get rid of 'abstractions' and  
'externals'.  They should probably called 'libraries', or something  
like that.

.hc

>
>
> fgmsdr
> IOhannes
>
>




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

You can't steal a gift. Bird gave the world his music, and if you can  
hear it, you can have it. - Dizzy Gillespie







More information about the Pd-list mailing list