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

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.

On Sep 2, 2008, at 8:20 AM, Marcus Boerger wrote:
> 1) Copy everything to SVN, it doesn't hurt having a few more things
> there, if they won't be used, they won't be... if they are, they are
> at least available. Maybe have a top level /old-stuff

This was my original proposal. I'm willing to go with it, if no one  
has a good reason not to.

> 3) Let's do /php-src/trunk/ext... php-src/branches/PHP_5_3/ext...
> to clarify that matter.

Agreed.

> 4) We should either have 'experimental' next to trunk/tags/branches
> or we should put experimental stuff into tags. Either way we need to
> control who can create tags, branches and/or experimental directories.
> Personally I'd favor an interface that allows select users to create
> directories under tags that get prefixed by username. E.g. if I used
> that to create a tree for the re2c lexer rewrite developemnt I'd end
> up with php-src/tags/helly_re2c_lexer/...

As sean pointed out, this would go under branches, not tags. Otherwise  
it's definitely a sound idea. Please add the "prefixed by username"  
idea to the Wiki pages somewhere. Meanwhile, an experimental/  
directory will almost definitely go alongside trunk/ tags/ branches/  
in the structure.

> 5) No parallel CVS supported integrated into the SVN repository. A
> gateway that can access SVN Data in a CVS way is nice to have. The
> easiest way is a cronjob that does snapshots into a readonly CVS
> repository.

I don't feel the need for this, but I invite discussion on whether or  
not it's useful.

Here is the current proposed structure:

obsolete/
  <old projects>
pear/
  <pear project>/
   trunk/
   tags/
   branches/
   experimental/
  <pear project>/
   ...
pecl/
  <pecl project>/
   trunk/
   tags/
   branches/
   experimental/
  <pecl project>/
   ...
php-src/
  trunk/
   zend/
   tsrm/
   ext/
    standard/
    ...
    <externals linked to pecl>/
  tags/
   PHP_5_3_0/
    zend/
    tsrm/
    ext/
     standard/
     ...
     <externals linked to pecl>/
  branches/
   PHP_5_3/
    zend/
    tsrm/
    ext/
     standard/
     ...
     <externals linked to pecl>
  experimental/
php-doc/
  trunk/
   en/
   fr/
   jp/
   ...
  branches/
  tags/
  experimental/
phd/
  trunk/
  branches/
  tags/
  experimental/

Yes, this gives every single PEAR and PECL extension its own branches,  
tags, and trunk; I feel this necessary.

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