[PD-dev] svn:externals "sucks", or tracking changes in Gem

[Hans-Christoph Steiner]

Sorry, I am very slammed right now, so I didn't have time to look at  
this build issue.  I moved everything to point to the Gem SVN now, so  
it should work fine.

Instead of svn:externals, another option is to import gem releases  
into the pure-data SVN.  I am working a lot now with openembedded,  
and basically all the code used there is pegged to a certain release  
version.  With big distros like Pd-extended, that is necessary in  
order to get anything released.  I suppose it would also be possible  
then to have a Gem-only nightly build.

Moving gem development to the pure-data SVN would also solve this  
issue, so there are many ways to do it.  If someone wants to run a  
build farm and maintain Pd-extended, I'll happily defer to them on  
these questions.  But right now, for me, svn:externals solves no  
problems and also creates new problems.

.hc

On Aug 27, 2008, at 9:30 PM, zmoelnig at iem.at wrote:

> some of the autobuilds have been failing for ages now, because of a
> change introduced into Gem's directory layout, the autobuild system's
> adaption to it and some somewhat out-of-sync autobuild hosts.
>
> Subject: [PD-cvs] autobuild: pd-main+libs debian-testing-i386
> Subject: [PD-cvs] autobuild: pd-puredyne debian-testing-i386
> Subject: [PD-cvs] autobuild: pd-main+libs ubuntu-hardy-i386 2008-08-26
>
> all of these are failing, because of the following history:
> - Gem has switched form CVS to SVN
> - the autobuild system (or rather: the human that is behind that:
> hans) has tracked Gem's switch to svn
> - i have tidied up Gem a bit and moved the "manual/" into the  
> "doc/" section
> - hans has adapted the autobuild system accordingly
> - somehow some machines got out of sync: they have updated their
> autobuild system to include the change in the directory layout, but
> are still using the CVS version of Gem (where this change has not yet
> occured)
> - these machines fail to build each night
>
> i think it is related to the re-occuring (e.g. see the current thread
> on flext-svn) discussion of svn:externals
>
> as i can see it, there are 2 main arguments against svn:externals
> - (fear of) problems when doing "svn update" (e.g. due to unofficial
> certificates)
> - (fear of) problems when re-structuring the repository (e.g. when
> importing code that was previously integrated via svn:externals)
>
> as can be seen by the example above, also the alternative approach
> (using scripts to explicitely checkout a remote repository) is not
> foolproof (well nothing is), and actually exhibits the very problems
> because of which it is used (apart from legacy reasons for sticking to
> them)
>
>
> mfg.dsr
> IOhannes
>
>
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
>
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev







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

"It is convenient to imagine a power beyond us because that means we  
don't have to examine our own lives.", from "The Idols of  
Environmentalism", by Curtis White