Re: Proposed repository structure

Hi,

just some more thoughts:

On Mon, 2008-09-01 at 17:05 -0400, Gwynne Raskind wrote:
> - All projects will use the standard SVN trunk/ tags/ branches/  
> structure.
>     Pros: Works with various tools that expect it, mirrors CVS'  
> behavior for those not used to SVN
>     Cons: Less flexible

so from your structure below: trun/php-src trunk/pear or
pear/package/trunk, php-src/trunk/ ?
What impact does this have on user account handling? (developer X should
have write access to ext/foobar in all active branches)

> - Zend and TSRM will remain separate projects from php-src/
>     Pros: Again, mirrors the old CVS layout
>     Cons: It's ugly!

I'd like an agreement to move stuff that belongs together together...

> - All -web/ projects will lose the -web/ suffix and be put under a  
> web/ master directory.
>     Pros: Organizationally more structured
>     Cons: It's a change from CVS

Does "all" include pearweb and similar?

> - Obsolete projects which aren't touched anymore will NOT be converted  
> from CVS
>     Pros: Avoids clutter in SVN
>     Cons: CVS would have to be maintained indefinitely to preserve the  
> history

If we do that we should keep the ,v files-

> Here's a quick overview of the proposed root of the SVN repository:
> 
> pear/
>   <various pear modules>
> pecl/
>   <various pecl modules>
> php-doc/

with subdirs for translations and phpd, what about peardoc? that's in
pear/ ?

> php-src/
> tsrm/
> web/
>   php/
>   php-doc/
>   php-master/
>   smarty/
>   <etc.>
> zend/ <this will be Zend 2>

So and what's up with extensions in general? Have *all* of them in pecl/
and put them using svn:externals in "release trees"?

Can we get some space for experimental developer branches?

And what about all the other questions, the ones about life, universe
and everything? (aka. tomorrow I'll most likely ask a few more
questions, don't take this as final :-) )

johannes