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

On Mon, 2008-09-01 at 18:07 -0400, Gwynne Raskind wrote:
> > 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.

Then we should try to find a way to make this as automatic as possible,
else we have some administrative hell :- or we need to be more open when
granting accounts -)

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

There's a quit strong reason to put them in the same path: Branching and
tagging. Branching all of them and updating the externals feels bad.

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

Any opinion from some pear people? - I don't know whether the websites
have anything in common, I don't know if the PEAR Website and Pear
repository have a thing in common :-)

> >> Here's a quick overview of the proposed root of the SVN repository:

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

What's with translations and "general" stuff (everything outside the en/
dir in the current structure)

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

Hm, same thing as above: What's with tagging and branching? When first
mentioning this idea I thought: Well many extensiosn work with tiny
#ifdefs on HEAD and 5_3, so maybe it'S a nice thing to have them in a
seperate branch, thinking a bit more (and after enjoying the easyness of
the current infrastructure to tag the tree and build a release - just
two commands to type (cvs tag && ./make_dist)) it sounds like a lot of
scripting magic needed for the tagging part.

One approach there might be to copy php-src-trunk to the tag location
and then copy the stuff linked using svn:external, the problem then is
that it's harder to find all tags of an extension (or does svn1.5 help
there?) but tagging each extension individually looks like a big
tag-soup.

So probably it's best to do svn mv? I don'T really know :-)

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

What tools, and why fail? Basically these tools shouldn't have to care
too much, as these branches are for devs for playing around, the biggest
problem I can see there are commit mails, for some changes it might be
nice to send them out, for other stuff it might be annoying for the
commit list...

> > And what about all the other questions, the ones about life,  

Right, one more: Where do talks fit in in this structure? In the root?
To the web?

> > universe and everything? (aka. tomorrow I'll most likely ask a few  
> > more questions, don't take this as final :-) )
> 
> 42 :).

The final question (for this mail) now is: What's the actual question,
now having a (few) answer(s)? :-)

johannes