[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