Re: [SVN-MIGRATION] Re: Proposed repository structure

FWIW, my vote on the issue of extensions is that all extensions live  
in pecl and that we use externals to pull them into the main tree.

externals can be pegged at a particular tag for releases and point to  
the trunk in the trunk.

At release time those externals a pointed at the best available tag,  
assessed on an extension-by-extension basis, or even can be left  
pointing at the tip--the whole repo version number makes it easy to  
figure out exactly what shipped.

--Wez.

On Sep 2, 2008, at 3:46 PM, Gwynne Raskind wrote:

> On Sep 2, 2008, at 2:37 AM, Derick Rethans wrote:
>>> So and what's up with extensions in general? Have *all* of them in  
>>> pecl/
>>> and put them using svn:externals in "release trees"?
>> That I don't think is a good idea. Those extensions that we bundle
>> should be in every normal checkout for two reasons: 1. we easily spot
>> breaks in compilation. 2. people can use a non-release while  
>> developing
>> projects to make sure that changes to PHP don't break their code (and
>> v.v.) As everything lives in the same repository, I don't even know
>> whether :externals works here (as it's not external). I think that
>> leaving it like it is now is fine, and moving in/out pecl can just  
>> be an
>> "svn mv" or "svn cp".
>
> Externals can easily be cross-project instead of cross-repository;  
> that's no issue. With an external linking things into ext/,  
> compilation errors will be spotted identically as if they were  
> actually there. As for using a non-release to develop, that's also  
> handled by peg revisions in the externals declaration. With the  
> exception of the "true core" extensions like standard and such,  
> there shouldn't be any extensions that can't stand on their own in  
> pecl anyway.
>
> On Sep 2, 2008, at 2:39 AM, Derick Rethans wrote:
>>>> I'd like an agreement to move stuff that belongs together  
>>>> together...
>>> So would I, but as I said on IRC, I'd rather get moving with the  
>>> move than
>>> argue the politics of this particular problem. If you can come up  
>>> with a
>>> solution that those involved are alright with, please let me know.
>> I'm with Johannes here - they're an integral part, so they should go
>> where they belong. It has been causing problems in the past (checking
>> out php-src instead of php5 f.e.), and *not* having them in the  
>> correct
>> places again would require scripts to put things in the correct  
>> place.
>
> That's a valid point. Again, it's the politics I'd rather not  
> personally deal with. I'll create the new SVN repository with TSRM  
> and Zend merged in, but I'll be counting on you and others to handle  
> questions of licensing and such, as I don't have the first clue  
> about them.
>
> [...]
> Yes, this gives every single PEAR and PECL extension its own  
> branches, tags, and trunk; I feel this necessary.