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

[Hans-Christoph Steiner]

On Mon, 8 Sep 2008, IOhannes m zmoelnig wrote:

> Hans-Christoph Steiner wrote:
>> 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.
>
> thanks
>
>> 
>> 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.
>
> yes that would be an option, though it might be even more work than it is 
> now.
> i still think that the svn is more than just the release system for 
> pd-extended.

I also think it is not just a release system for Pd-extended.  The 
question is more what it should be going forward. I think the pure-data 
repository has worked really well in bringing the community of developers 
together.  But it is not working so well now, perhaps because it isn't 
clearly defined, or because we have different needs now.

- For Pd-extended, there needs to be a repository to do code freezes and 
bug fixes, branches work pretty well for that.

- for making a central place to find code, I think we'd be better off with 
a 'libraries' page like http://processing.org has.

- for nightly builds, I think that ideally there would be a way to build 
libraries separately from Pd-extended, but that's a matter of someone 
doing the work.  Running something like buildbot would be really nice.

That's my two bits.

.hc



>> 
>> Moving gem development to the pure-data SVN would also solve this 
>
> right, but i won't do that;
>
>> 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.
>
> no problem; i just wanted to point out that it seemed to me that the main 
> problem with svn:externals (as you described it previously) also exists in 
> the current layout we are using.
>
> mfga.sdr
> IOhannes
>

 	zen
 	   \
 	    \
 	     \