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

On Sep 1, 2008, at 5:50 PM, Johannes Schlüter 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/ ?

The latter; 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)

Since we're using DAV, we can use authz to allow/disallow on a path-by- 
path basis. It does present some issues in managing developer access  
to branches, but SVN's tag/branch structure doesn't allow for much  
flexibility in that area. A developer will have to be granted access  
to branches on a branch-by-branch basis since extensions won't have  
their own trunk/tags/branches subdirectories.

>> - 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...

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.

>> - 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?

Ideally, yes.

>> - 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-

Agreed.

>> 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/ ?

It should really look like this:
phd/
doc/
  php/
  pear/
  pecl/

Unfortunately, to some extent that would require a reorganization of  
the docs themselves. I'd appreciate any thoughts Philip and Hannes  
have on that subject.

>> 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"?

Ideally yes, especially since that would make the above-mentioned per- 
person access problem much simple, but again this is a question of  
major reorganization. The PECL and php-src people will have to agree  
on that one.

> Can we get some space for experimental developer branches?

Deviating from the trunk/ tags/ branches/ layout means that most tools  
will fail to recognize such branches entirely. Sticking them under  
trunk/experimental/ might work. Adding an experimental/ at the top  
would make for those branches going completely unnoticed by automation.

> 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 :-) )

42 :).

-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."