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